컴플라이언스팀에서 그동안 조사했던 것들(isms-p 기반 컴플라이언스 점검) 보고서로 정리하였고, 노션-보고서 부분에 업로드 해두었습니다!
개요
컴플라이언스팀의 ISMS-P 점검 보고서가 올라왔다. 이 보고서를 계기로 인프라팀이 조회 권한을 내주고, 확인 불가 항목을 다시 점검하고, 사고대응 절차를 문서로 정리하기 시작했다. 다만 지금은 이 과정을 두 사람이 기억하고 챙겨서 돌아간다. 그걸 어떻게 바꿀지가 다음 일이다.
보고서를 읽는 기분은 PR 리뷰를 받을 때와 비슷했다. 내가 만든 것을 다른 사람이 다른 전제에서 읽고, 당연하게 넘긴 조건에 질문을 붙인다. 이번엔 코드 대신 우리가 만든 인프라 설정이 그 리뷰를 받았다.
무엇을 조사할지 찾아보기
컴플라이언스팀을 두게 된 이유는 단순하다. PM인 나는 이 분야를 잘 몰랐지만, 두 팀원이 면담에서 해보고 싶다고 했다. 배우기 위해 모인 학생 조직에서, 하겠다는 사람이 있는 분야를 PM이 모른다는 이유로 접어두기는 불가능했다.
평소에 관심이 있던 인프라와 달리 컴플라이언스에는 내가 알던 것이 전혀 없었다. 그래서 처음 위임한 일은 정해진 업무의 실행이 아니라 업무의 범위와 근거를 찾아오는 것이었다. 두 사람은 그 내용을 조사해 팀이 읽을 수 있는 문서로 정리했다. 덕분에 인프라팀과 항목 단위로 이야기할 수 있게 됐다.
확인 불가 항목 다시 점검하기
이전 점검(
근두운 기술 블로그근두운 컴플라이언스 통제항목 점검 현황
근두운 기술 블로그
근두운 기술 블로그근두운 컴플라이언스 통제항목 점검 현황근두운 컴플라이언스 통제항목 점검 현황
이번에는 선정한 통제항목을 컴플라이언스팀이 실제로 콘솔을 열고 하나씩 확인해보며, 현재 상황과 점검한 내용을 기록했다. IAM·Logging·Detection은 필자가, S3/Data·Incident Response는 팀 내 다른 담당자가 같은 방식으로 점검했다.
근두운 기술 블로그내부 피드백 받기
점검은 ISMS-P 인증기준, 개인정보 보호법, 개인정보의 안전성 확보조치 기준을 참고해 IAM, Logging, Detection, S3/Data, Incident Response 다섯 영역 23개 항목으로 구성됐다. 사용자 계정에 MFA가 적용되어 있는지, 로그 보존을 확인할 수 있는지, 사고 대응절차와 연락체계가 있는지 같은 질문을 AWS 콘솔과 내부 문서로 확인했다.
인프라팀이 "MFA 안 걸린 계정이 있다"고 말했다면 평소의 내부 피드백으로 넘겼을 것이다. 그런데 별도 팀이 외부 통제기준을 근거로 같은 사실을 확인하고 판정을 보고서에 남기자 읽는 태도가 달라졌다. 설정 하나를 고치는 일에 더해, 점검 결과를 어떻게 처리했는지 추적할 수 있게 남기는 일까지 팀의 과제가 됐다.
ISMS-P 번호를 우리 구성과 대조할 생각은 애초에 내게 없었다. 시야 밖의 질문이 다른 사람의 조사에서는 구체적인 점검 항목으로 존재하고 있었다.
대응 절차를 문서로 정리하기
피드백 결과 심각한 사항들은 없었던 편이다. 앞으로 준비 중인 사항이거나, 인프라가 없기 때문에(이제 중간을 넘겼다!) 고려할 필요는 없는 항목들 정도가 있었다. 그러나 사고 대응 절차에 대해서는 조금 신경 쓸 필요가 있을 것 같았다. 아무리 학습을 위한 학생 조직이라도, SecOps 실습이라는 명분이 있는 한 시도는 해봐야 하지 않겠는가?
사고가 나면 누군가는 자원을 격리하려 하고, 누군가는 서비스 지속을 걱정하고, 누군가는 증적과 보고를 챙긴다. 누가 무엇을 결정하고 어떤 순서로 전달할지 정해두지 않으면, 평소 드러나지 않던 우선순위 충돌이 사고와 동시에 표면화된다. 그때 합의를 시작하기에는 늦다. 절차서는 그 조율을 앞당겨두는 수단이다.
지속 가능한 점검 방식 찾아보기
이번에 확인한 MFA나 로그 설정은 이후 바뀔 수 있고, 새 자원은 점검표가 만들어진 뒤에 생긴다. 보고서의 '충족'은 확인한 시점과 범위 안에서의 판정이다. 그래서 컴플라이언스팀에 재사용 가능한 점검 양식과 함께 지속 점검을 자동화할 방법을 조사해달라고 요청했다. IaC가 구성을 코드로 남기듯, 점검 조건도 반복 실행하고 결과를 추적할 수 있는 형태로 옮길 수 있을 것이다. Policy as Code, Compliance as Code가 여기서 관심사가 됐다.
또한, 이번 조사에서 담당자의 기억 없이도 돌아가는 점검이 필요하다고 느꼈다. 상태 조회로 확인되는 설정은 코드로 점검하고 이력을 남기되, 예외 판단이나 절차의 실제 운영 여부는 사람이 검토한다. 어디까지 기계가 판정하고 어디에 사람이 필요한지는 이제 설계할 과제다.
결론
컴플라이언스팀에 부탁한 것은 "무엇을 해야 하는지 알아봐달라"는 것이었다. 두 사람은 그 답과 함께 우리가 답해야 할 질문까지 가져왔고, 그 질문이 권한 요청과 재점검을 거쳐 인프라 설정과 팀 문서를 바꿨다.
보고서를 처음 열 때는 긴장이 앞섰다. 열어보니 큰일은 없었다. 팀 메신저에 몇 줄 적었다면 흘려봤을 내용이 근거와 통제번호와 판정을 달고 오니 무게가 달랐다. 그렇다고 불쾌하지는 않았다. 평가는 필요한 것이었고, 내가 보지 못한 구멍을 누군가 찾아오는 감각은 오히려 신선했다. 확인 불가 항목이 권한을 받아 하나씩 지워지는 걸 보면서는 PM으로서 보람도 있었다.
남은 것은 상태 조회로 확인되는 항목을 코드로 옮기는 일과, 사람이 봐야 할 항목을 골라내는 일이다. 이번 점검은 두 사람이 기억하고 챙겨서 시작됐다. 다음 점검은 그러지 않아도 도착하는 형태로 만들면 좋지 않을까?
