ISO 27001 인증 준비 6일차.
첫 주에는 회사의 조직과 업무, 개인정보, 시스템 등을 전반적으로 살펴봤다면 둘째 주부터는 조금 더 깊은 곳으로 들어가기 시작했다.
그리고 6일차에는 방화벽을 들여다봤다.
사실 나도 어느 정도는 알고 있었다.
우리 쪽에 문제가 많다는 것을.
오래 운영된 시스템도 많고, 서비스도 많다 보니 방화벽 정책이 깔끔하게 정리되어 있지 않을 것이라는 예상은 하고 있었다.
그런데 역시나.
하나씩 실제 설정을 열어보기 시작하니 생각했던 것보다 상황이 심각했다.
알고 있던 문제와 직접 확인한 문제는 달랐다
“문제가 많을 거야.”
이렇게 생각하고 있는 것과 실제 문제를 하나하나 확인하는 것은 완전히 달랐다.
특히 먼저 눈에 들어온 것은 관리자 권한에 대한 관리였다.
방화벽은 단순히 네트워크의 문을 열고 닫는 장비가 아니다.
잘못 설정하면 중요한 서버나 시스템에 불필요한 접근이 가능해질 수도 있고, 반대로 필요한 서비스가 막힐 수도 있다.
그만큼 관리자 권한을 가진 계정에 대한 관리가 중요하다.
그런데 실제로 하나씩 확인해보니 부족한 부분이 여러 곳에서 보였다.
누가 관리자 권한을 가지고 있는지,
로그인은 어떻게 이루어지는지,
관리자 세션은 어떻게 관리되는지,
어떤 IP 대역에서 접근할 수 있는지.
평소에는 그냥 “관리자가 접속할 수 있으면 되는 것 아닌가?”라고 생각할 수도 있는 부분이었다.
하지만 인증을 준비하면서 바라보니 질문이 달라졌다.
왜 이 사람이 관리자 권한을 가지고 있는가?
어디에서 접속할 수 있는가?
언제 접속했고, 그 세션은 어떻게 관리되는가?
그리고 문제가 생겼을 때 그 사실을 추적할 수 있는가?
이런 부분까지 확인해야 했다.
관리자 계정은 생각보다 무서운 존재였다
방화벽 관리자 계정은 일반 사용자 계정과는 차원이 다르다.
정책을 변경할 수 있고,
네트워크 접근을 허용할 수도 있고,
기존의 차단 정책을 수정할 수도 있다.
잘못된 변경 하나가 서비스 장애로 이어질 수도 있고, 반대로 너무 넓게 허용된 정책 하나가 보안상 큰 구멍이 될 수도 있다.
그런데 이런 권한을 가진 계정이 제대로 통제되지 않고 있다면 문제는 단순한 “계정 관리 미흡”으로 끝나지 않는다.
시스템 전체에 영향을 줄 수 있는 권한이 제대로 통제되고 있느냐의 문제가 된다.
그래서 앞으로는 관리자 계정의 권한을 보다 명확하게 관리하고, 접속 가능한 IP 대역이나 세션 관리도 정리할 필요가 있다는 것을 알게 됐다.
그런데 더 큰 문제는 방화벽 정책이었다
관리자 계정을 보고 나니 그다음에는 방화벽 정책이 눈에 들어왔다.
그리고 여기에서 또 한 번 막막함을 느꼈다.
정책이 너무 많았다.
서비스도 많고,
시스템도 많고,
오래전부터 운영된 환경이다 보니 지금 사용하고 있는 정책과 과거에 만들어진 정책이 섞여 있었다.
어떤 정책이 실제로 필요한 것인지,
어떤 정책이 더 이상 사용되지 않는 것인지,
왜 만들어졌는지,
누가 요청했는지.
하나씩 확인해야 했다.
문제는 시스템이 방대하다는 것이다.
“정리해야 한다”는 것은 알겠는데, 도대체 어디서부터 손을 대야 하지?
그게 솔직한 마음이었다.
모든 정책을 한 번에 건드릴 수도 없다.
잘못 수정했다가는 실제 운영 중인 서비스에 장애가 발생할 수 있기 때문이다.
결국 보안을 강화하는 것도 중요하지만, 현재 운영 중인 서비스를 망가뜨리지 않으면서 하나씩 정리하는 과정이 필요했다.
테스트용 정책은 정말 임시여야 한다
이 과정에서 또 하나 눈에 들어온 것이 있었다.
테스트를 위해 임시로 열어둔 정책들이었다.
사실 이것도 누구나 알고 있는 이야기다.
테스트를 위해 잠깐 포트를 열거나 접근을 허용했다면,
테스트가 끝났을 때 다시 닫아야 한다.
그런데 현실에서는 이게 생각보다 쉽게 놓친다.
“일단 테스트해야 하니까 열어두자.”
그리고 테스트가 끝난 뒤에는 다른 업무가 생긴다.
며칠 지나고,
몇 주 지나고,
어느 순간 그 정책이 왜 열려 있었는지 기억하는 사람도 없어질 수 있다.
그렇게 임시 정책이 상시 정책처럼 남게 된다.
이번에 방화벽을 보면서 바로 이런 부분이 관리 미흡에 해당할 수 있겠다는 생각이 들었다.
그래서 오히려 처음부터 임시 정책이라는 것을 명확하게 표시하고, 만료기간을 정해두는 방식이 좋겠다는 생각이 들었다.
예를 들어 테스트를 위해 정책을 추가한다면,
“이 정책은 테스트를 위해 생성했으며 ○월 ○일까지만 사용한다.”
라는 식으로 종료 시점을 명확하게 해두는 것이다.
그러면 누군가 정책을 검토할 때도 이유와 종료 시점을 바로 확인할 수 있다.
결국 여기에서도 중요한 것은 기술적인 설정 하나가 아니라 관리하는 방법이었다.
방화벽 정책을 바꾸는 것도 하나의 업무였다
방화벽 정책을 추가하거나 수정하거나 삭제하는 일은 생각보다 가볍게 보면 안 된다는 것도 다시 알게 됐다.
정책을 변경할 필요가 생기면,
누가 요청했는지,
왜 필요한지,
어떤 영향을 줄 수 있는지,
누가 검토했는지,
누가 승인했는지,
실제로 누가 작업했는지.
이런 과정이 남아 있어야 한다.
그리고 우리 쪽에서는 이러한 변경을 팀장 승인하에 진행하도록 체계를 잡는 것이 필요하다는 이야기가 나왔다.
이것도 결국 앞에서 계속 나왔던 이야기와 연결된다.
“누가 수정했는지 모르겠다.”
“왜 열었는지 모르겠다.”
“언제 삭제했는지 모르겠다.”
이런 상황을 만들지 않기 위해서다.
변경하기 전에 승인하고,
변경한 뒤에는 기록을 남기고,
나중에 문제가 발생하면 다시 추적할 수 있어야 한다.
결국 가장 중요한 것은 ‘증적’이었다
6일차까지 오면서 이제는 증적이라는 말을 들어도 예전처럼 단순한 문서 하나라고 생각하지 않게 됐다.
방화벽 정책 하나를 예로 들어도 그렇다.
정책을 추가했다면,
추가 요청 기록
→ 검토 기록
→ 승인 기록
→ 실제 작업 기록
→ 변경 결과
가 연결될 수 있어야 한다.
수정도 마찬가지고,
삭제도 마찬가지다.
그리고 나중에 누군가 물어본다고 생각해보면 훨씬 이해가 쉽다.
“이 정책은 왜 존재합니까?”
“누가 승인했습니까?”
“언제 변경됐습니까?”
“현재도 필요한 정책입니까?”
이 질문에 시스템이나 기록으로 답할 수 있어야 한다.
그래서 점점 확실해졌다.
인증에서 중요한 것은 단순히 보안 설정이 되어 있는가가 아니라, 그 보안 설정이 제대로 관리되고 있다는 것을 보여줄 수 있는가였다.
방화벽을 보고 나니 다시 막막해졌다
6일차가 끝나면서 기분이 묘했다.
첫 주에도 “할 일이 많다”는 생각을 했다.
그런데 이번에는 그 말의 의미가 달라졌다.
첫 주에는 해야 할 업무가 많다는 느낌이었다면,
이제는 현재 운영 중인 시스템의 문제를 실제로 하나씩 해결해야 한다는 부담감이 생기기 시작했다.
방화벽 정책만 해도 수없이 많다.
그것을 전부 확인해야 하고,
필요한 것은 유지하고,
불필요한 것은 정리하고,
잘못된 것은 수정하고,
임시 정책은 기간을 정하고,
관리자 권한도 정리해야 한다.
그런데 한 가지를 고치려면 다른 시스템과의 연결 관계도 다시 확인해야 한다.
그래서 더 막막했다.
하지만 동시에 한 가지는 분명해졌다.
“우리가 무엇을 고쳐야 하는지는 조금씩 보이고 있다.”
예전에는 그냥 막연하게 “보안이 부족하다”라고 생각했다.
이제는
어떤 계정이 문제인지,
어떤 정책이 문제인지,
어떤 절차가 없는지,
어떤 기록이 부족한지
조금씩 구체적으로 보이기 시작했다.
6일차를 마치며
방화벽을 하나씩 뜯어보면서 느낀 것은 의외로 단순했다.
보안은 설정값 하나를 바꾸는 것으로 끝나는 일이 아니었다.
누가 관리하는지,
왜 그렇게 설정했는지,
언제 변경했는지,
누가 승인했는지,
필요한 기간이 끝났다면 제대로 닫혔는지.
이 모든 과정이 이어져야 했다.
그리고 그 과정을 나중에 누군가 확인할 수 있도록 기록이 남아 있어야 했다.
결국 6일차에 가장 크게 배운 것은 이것이었다.
“보안은 잘하는 것만큼, 잘하고 있다는 것을 증명할 수 있어야 한다.”
방화벽 정책 하나가 그 사실을 아주 잘 보여주고 있었다.
그리고 이제 알 것 같다.
앞으로 ISO 27001을 준비하면서 가장 많이 듣게 될 단어 중 하나가 아마 ‘증적’이 될 것이라는 것을.