무엇을 지켜야 하는가

이 시스템에는 지켜야 할 정보가 들어갑니다. 직원의 인사 정보(부서, 직위, 연락처, 시급 이력), 결재 문서의 내용, 근태와 휴가 기록, 그리고 기관에 따라 이용자 정보가 들어갈 수 있습니다. 결정권자가 물어야 할 질문은 "이 정보에 누가 접근할 수 있고, 그것을 무엇이 보장하는가"입니다.

세 겹의 문

그림 4-1 · 세 겹의 접근 통제

접근은 세 겹으로 통제됩니다.

첫째 겹, 도메인 제한. 기관 이메일 도메인(예: @example.or.kr)의 구글 계정만 로그인할 수 있게 설정할 수 있습니다. 외부인은 로그인 단계에서 막힙니다.

둘째 겹, 승인제. 기관 도메인 계정으로 로그인해도 곧바로 들어올 수 없습니다. 첫 로그인은 '접근 신청'으로 접수되고, 관리자가 승인해야 데이터에 접근할 수 있습니다. 퇴사자는 승인을 취소하면 그 즉시 접근이 막힙니다.

셋째 겹, 서버 측 보안 규칙. 앞의 두 겹이 뚫리더라도 — 예컨대 누군가 기술적 지식으로 화면을 우회해 데이터베이스에 직접 접근을 시도하더라도 — 데이터베이스 자체에 설정된 보안 규칙이 서버 쪽에서 차단합니다. 이 규칙은 "승인된 계정만 업무 데이터를 읽고 쓸 수 있다", "직원 명부와 설정은 관리자만 고칠 수 있다", "감사 로그는 누구도 고치거나 지울 수 없다" 같은 원칙을 데이터베이스 수준에서 강제합니다. 화면을 어떻게 조작하든 이 규칙 위에서는 예외가 없습니다.

세 번째 겹이 실질적인 보호막이라는 점을 강조해 두고 싶습니다. 웹 시스템의 화면은 누구나 열어 볼 수 있으므로 화면에서 메뉴를 숨기는 것은 보안이 아니라 편의입니다. 진짜 통제는 서버 쪽 규칙 하나이고, 그래서 이 책의 설치 절차는 보안 규칙 게시를 건너뛸 수 없는 단계로 못 박아 두었습니다.

세부 권한

승인된 직원이라고 모든 것을 볼 수 있는 것은 아닙니다. 직원 명부의 민감 정보(시급 등)는 관리자만 수정할 수 있고, 감사 로그는 관리자만 열람합니다. 관리자 지정 자체도 관리자만 할 수 있으며, 일반 직원이 스스로를 관리자로 올릴 수 있는 경로는 보안 규칙 차원에서 막혀 있습니다. 문서번호 채번 기록은 줄어들 수 없게 되어 있어 문서번호가 중복 발급되는 일도 막습니다.

데이터는 어디에 있는가

데이터는 구글의 클라우드 데이터베이스(Firestore)에 저장되며, 설치할 때 저장 위치로 서울 리전을 선택합니다. 데이터는 기관이 만든 기관 소유의 구글 프로젝트 안에 있습니다. 개발자나 배포자가 접근할 수 있는 구조가 아닙니다. 이 점은 상용 서비스와 뚜렷이 다른 부분입니다. 상용 서비스는 업체의 서버에 우리 데이터가 있지만, 이 시스템은 우리 프로젝트에 우리 데이터가 있습니다. 백업도 관리자 화면에서 전체 데이터를 JSON 파일로 직접 내려받는 방식이라, 언제든 데이터 전체를 손에 쥘 수 있습니다.

이용자 개인정보를 다룬다면

직원 행정만 다루는 기관은 여기까지로 충분합니다. 다만 이용자 관리 기능까지 쓰면서 이용자의 연락처·주소를 저장하려는 기관은 한 가지를 더 고려해야 합니다. 기본 상태에서 이 정보는 암호화되지 않은 평문으로 저장됩니다. 이를 위해 암호화 프록시라는 선택 기능이 준비되어 있어, 연결하면 연락처와 주소가 암호화되어 저장됩니다. 이용자 개인정보를 다루는 기관은 이 기능의 연결(5부에서 다룹니다)을 도입 조건으로 삼으시길 권합니다.

남는 위험은 무엇인가

정직하게 적어 둡니다. 이 시스템의 보안에서 가장 약한 고리는 기술이 아니라 설정입니다. 보안 규칙을 게시하지 않고 운영하거나, 최초 관리자 계정을 방치하거나, 퇴사자 계정 승인을 취소하지 않는 것 — 사고가 난다면 이런 지점일 것입니다. 그래서 이 책은 해당 단계마다 반복해서 주의를 표시해 두었고, 부록에 점검 체크리스트를 실었습니다. 도입을 결정하신다면, 담당자에게 "체크리스트대로 했는지"만 확인하셔도 관리 감독으로서는 충분합니다.