ISMS 대응에서 개발팀이 확인한 권한과 변경 이력
ISMS 대응을 하면서 개발팀도 운영 접근 권한과 변경 이력, 작업 기록을 함께 확인해야 했습니다. 절차가 있다고 설명하는 것 외에, 실제 작업에서 그 절차를 어떻게 적용했고 어떤 기록이 남았는지 보여 줄 수 있어야 했습니다.
개발과 운영을 따로 떼기 어려운 부분이었습니다. 코드를 고치는 사람과 배포하는 사람, 운영 데이터를 확인할 수 있는 사람이 누구인지부터 살펴봐야 했습니다.
인증 범위와 개발팀의 작업
ISMS는 정보보호 관리체계를 다루고, ISMS-P는 여기에 개인정보보호 관리체계를 함께 다룹니다. 공식 인증기준에서도 관리체계 수립·운영과 보호대책, 개인정보 처리 단계별 요구사항을 구분합니다.
개발팀에서는 적용되는 인증 범위와 내부 정책에 맞춰 맡은 시스템의 권한·변경 관리·운영 기록을 확인해야 합니다. 어떤 로그를 얼마나 보관할지, 어떤 변경에 승인이 필요한지를 모든 서비스에 같은 숫자와 절차로 적용할 수는 없습니다.
운영 접근 권한
운영 서버와 DB, 배포 도구에 접근할 수 있는 사람을 확인하고, 업무상 필요한 권한인지 살펴봤습니다. 한 번 받은 권한이 역할 변경 뒤에도 그대로 남아 있지 않은지 확인하는 일도 필요했습니다.
평소 접근을 제한한다면 장애 때 필요한 권한을 얻는 경로도 함께 준비해야 합니다. 요청할 곳과 승인 담당자, 사용 뒤 회수하는 절차가 정리돼 있어야 긴급 상황에서 임시로 권한을 넓힌 채 남겨 두지 않을 수 있습니다.
코드 변경과 운영 반영의 연결
변경 요청과 PR, 리뷰·테스트 결과, 배포 기록이 이어져야 어떤 수정이 운영에 들어갔는지 설명할 수 있습니다. 코드 리뷰 기록이 있다는 것과 검토한 버전이 실제로 배포됐다는 것은 별도입니다.
당시에도 작업 티켓과 코드 변경을 연결해 이력을 확인했습니다. 보안 점검에 제출할 문서를 따로 만드는 것보다, 평소 작업에서 남기는 기록을 따라갈 수 있게 하는 것이 중요했습니다.
긴급 변경도 기록에서 빠지지 않아야 합니다. 배포를 서둘렀다면 이후에라도 변경 이유와 확인 결과, 남은 작업이 연결돼 있어야 같은 변경을 다시 검토할 수 있습니다.
운영 기록과 데이터 노출
운영 기록에는 누가 언제 어떤 작업을 했는지 확인할 단서가 필요합니다. 동시에 그 기록에 인증 정보나 고객 데이터가 불필요하게 섞이지 않아야 합니다. 조회 권한, 보관 방식, 변경·삭제 권한도 함께 확인해야 합니다.
테스트 데이터를 준비할 때도 단순히 이름을 바꿨다는 이유만으로 안전하다고 볼 수는 없습니다. 가명처리와 익명처리는 다른 개념이며, 테스트에 필요한 데이터 범위와 사내 처리 기준에 맞춰 준비해야 합니다.
점검 이후의 관리
접근 권한과 시스템 구성은 계속 바뀝니다. 점검 시점의 목록만 보관하면 이후 변경은 빠질 수 있어, 권한 변경과 배포·장애 대응 과정에서 기록을 남기는 방식이 필요했습니다.
ISMS 대응에서 개발팀이 다룬 것도 이런 운영 과정이었습니다. 문서에 적힌 절차와 실제 작업 기록이 맞는지 확인하고, 둘 사이에 빠진 부분을 보완하는 일이었습니다.
다음 글에서는 재해복구 계획과 실제 훈련에서 확인한 항목을 살펴보겠습니다.