ISO 27001 인증 준비 10일차.

요즘 하루하루가 너무 바쁘다.

아침에 출근해서 미팅을 하고,

미팅이 끝나면 또 다른 미팅을 하고,

그 사이에 필요한 자료를 찾고,

확인해야 할 내용을 정리하고,

다시 관련 부서와 이야기를 나눈다.

이렇게 하루가 지나간다.

문제는 하루가 끝났다고 일이 끝나는 것이 아니라는 것이다.

오늘 들었던 이야기를 정리하다 보면 어제 이야기했던 내용과 연결되고,

그걸 따라가다 보면 또 확인해야 할 것이 생긴다.

그래서 요즘은 솔직히 머릿속이 조금 어지럽다.

그래도 컨설팅을 받으면서 하나씩 기준이 잡히고 있다는 느낌은 있다.

10일차에는 특히 개발자와 운영자의 역할 분리에 대한 이야기를 많이 들었다.

개발자가 개발하고 운영까지 하면 안 되는 걸까?

우리 회사처럼 규모가 아주 크지 않은 곳에서는 개발자와 운영자를 완전히 분리하는 것이 쉽지 않다.

한 사람이 개발도 하고,

서버도 보고,

배포도 하고,

장애가 발생하면 직접 대응하기도 한다.

사실 이런 환경은 흔하다.

나 역시 현실적으로 충분히 이해하고 있는 부분이다.

그런데 ISO 27001을 준비하면서 보니,

“현실적으로 그렇게 운영되고 있다”는 것과 “그렇게 운영하는 것이 바람직하다”는 것은 다른 문제였다.

개발자가 코드를 작성하고,

그 개발자가 직접 운영 서버에 배포하고,

그 결과를 자기 스스로 확인하는 구조라면

통제 측면에서 문제가 생길 수 있다.

특히 중요한 시스템일수록 한 사람이 모든 권한을 가지고 있는 구조는 위험할 수 있다.

컨설팅 과정에서는 그래서 개발과 운영의 역할을 가능한 한 분리하고, 최소한 상위 책임자의 검토와 감독을 두는 방식이 필요하다는 설명을 들었다.

작은 회사에서는 어떻게 해야 할까?

여기에서 현실적인 고민이 하나 생긴다.

대기업처럼 개발팀, QA팀, 운영팀, 보안팀을 모두 따로 만들 수 있다면 좋다.

개발자는 개발만 하고,

운영자는 운영만 하고,

보안담당자는 보안만 본다.

그런데 작은 회사에서는 이게 쉽지 않다.

한 명이 여러 역할을 해야 하는 경우가 많기 때문이다.

그렇다고 해서 “인원이 부족하니까 어쩔 수 없다”라고 끝낼 수도 없었다.

그래서 내가 받아들인 현실적인 방법은 역할을 완전히 분리하지 못하더라도 통제 절차를 분리하는 것이었다.

예를 들어 개발자가 직접 배포할 수밖에 없는 환경이라면,

배포 전에 팀장이나 관리자의 검토와 승인을 받고,

배포 과정은 기록으로 남기고,

필요하면 배포 결과를 다시 확인하는 식이다.

즉 사람을 완전히 나누지 못하더라도,

권한과 승인, 검토 절차를 통해 상호 통제를 만들어야 한다는 것이다.

이 부분은 우리 회사 같은 환경에서는 상당히 현실적인 방법이라는 생각이 들었다.

배포할 때 누군가는 봐야 했다

개발 과정에서 가장 민감한 순간 중 하나는 역시 배포였다.

개발자가 프로그램을 만들었다.

그러면 바로 운영 서버에 올리면 될까?

컨설팅 과정에서 들은 이야기는 그렇지 않았다.

배포 전에

무엇이 변경되는지,

왜 변경하는지,

어떤 영향이 있는지,

테스트는 했는지,

문제가 발생하면 어떻게 대응할 것인지

등을 확인하고,

팀장이나 관리자가 이를 검토하거나 승인하는 절차가 필요하다는 것이었다.

그리고 실제 배포 결과도 기록으로 남겨야 한다.

누가 개발했고,

누가 검토했고,

누가 승인했고,

언제 배포했고,

어떤 버전이 적용됐는지.

이런 기록이 있어야 나중에 문제가 발생했을 때 원인을 추적할 수 있다.

결국 배포라는 것도 단순한 기술 작업이 아니라

관리해야 하는 업무 프로세스라는 것을 다시 한번 느꼈다.

모든 변경에는 승인과 기록이 따라왔다

이쯤 되면 이제 익숙해질 법도 하다.

무언가 변경한다.

그러면 승인이 필요하다.

그리고 기록이 필요하다.

방화벽도 그랬고,

서버 프로그램 설치도 그랬고,

계정 권한 변경도 그랬다.

그리고 이번에는 개발 소스와 프로그램 배포까지 같은 원칙이 적용됐다.

처음에는 이런 절차들이 조금 번거롭게 느껴졌다.

“이것도 승인받아야 해?”

“이것도 기록을 남겨야 해?”

라는 생각이 들기도 했다.

그런데 반대로 생각해보면 이유는 명확했다.

운영 중인 시스템에서 문제가 발생했을 때

“누가 언제 무엇을 변경했는가?”

를 알 수 있어야 하기 때문이다.

변경 이력이 없다면 원인을 찾는 것조차 어려워진다.

그래서 개발과 운영이 분리되어 있지 않은 환경이라면 오히려 변경관리와 승인 프로세스가 더 중요할 수도 있겠다는 생각이 들었다.

개발자가 내부에 접속하려면 VPN과 MFA

그리고 이날 또 하나 중요하게 확인한 것이 있었다.

개발자가 외부에서 회사 내부 환경에 접속하는 경우 어떻게 할 것인가?

당연히 아무 방식으로나 접근해서는 안 된다.

VPN을 통해 내부망에 안전하게 접속할 수 있도록 하고,

여기에 MFA 같은 다중요소 인증을 적용하는 것이 중요하다는 이야기를 들었다.

특히 개발자는 일반 사용자보다 더 많은 시스템과 정보에 접근할 가능성이 있다.

소스코드에 접근할 수도 있고,

개발 서버를 사용할 수도 있고,

경우에 따라 운영 환경에 대한 접근권한이 있을 수도 있다.

그렇기 때문에 외부에서 내부로 들어오는 경로를 더 엄격하게 관리해야 한다는 것이다.

누가 접속했는지,

언제 접속했는지,

어디에서 접속했는지,

어떤 방식으로 인증했는지,

어떤 시스템에 접근했는지.

이런 부분들이 추적 가능해야 한다.

사실 나도 이런 내용 자체는 알고 있었다.

VPN이 필요하다는 것도 알고 있었고,

MFA가 중요하다는 것도 알고 있었다.

그런데 이번 ISO 27001 준비를 통해 다시 한번 느끼게 됐다.

“알고 있는 것”과 “회사 시스템으로 제대로 적용하는 것”은 완전히 다르구나.

결국 보안 솔루션을 제대로 도입해야겠다는 생각

10일차에는 그래서 개인적으로 꽤 큰 결심을 하나 했다.

이번 기회에 보안 솔루션을 제대로 도입해서 적용해야겠다.

지금까지도 나름대로 보안에 신경을 쓰고 있다고 생각했다.

필요한 설정도 하고,

권한도 확인하고,

로그도 보려고 노력했다.

하지만 사람이 직접 챙기는 방식만으로는 한계가 분명했다.

회사의 시스템이 많아지고,

개발자가 많아지고,

배포가 반복되고,

외부 접속이 늘어날수록

수작업으로 모든 것을 관리하는 것은 점점 어려워진다.

그래서 VPN과 MFA 같은 기본적인 접근통제부터,

계정 및 권한관리,

접속기록,

변경이력,

배포이력 등을 체계적으로 관리할 수 있는 환경을 만들어야겠다는 생각이 들었다.

결국 사람의 주의에 의존하던 보안을 시스템의 통제를 통해 보완해야 한다는 것이다.

‘증적을 남기는 것’에서 ‘자동으로 남게 만드는 것’으로

지금까지 컨설팅에서 가장 많이 들었던 단어 중 하나가 증적이었다.

처음에는 필요한 문서를 만들고 기록을 남기면 된다고 생각했다.

그런데 10일차쯤 되니 생각이 조금 바뀌었다.

가장 좋은 것은 사람이 일부러 기록을 만드는 것이 아니라,

업무를 수행하는 과정에서 기록이 자동으로 남는 구조를 만드는 것이 아닐까?

개발자가 소스코드를 변경하면 변경 이력이 남고,

배포를 하면 배포 이력이 남고,

VPN으로 접속하면 접속 로그가 남고,

MFA를 통해 인증하면 인증 기록이 남고,

권한을 변경하면 그 요청과 승인 기록이 남는 구조.

이렇게 되면 담당자가 매번 별도의 문서를 만들어야 하는 부담도 줄어들 수 있다.

그리고 나중에 심사나 내부점검을 할 때도 필요한 기록을 찾아서 확인하기가 훨씬 쉬워질 것이다.

결국 내가 생각하는 좋은 보안체계는

“사람이 열심히 기록하는 체계”가 아니라 “정상적인 업무를 수행하면 필요한 증적이 자연스럽게 남는 체계”

에 가까워지고 있었다.

개발자에게 보안을 요구하는 것도 결국 회사의 책임이었다

시큐어 코딩 이야기도 계속 이어졌다.

개발자에게

“보안을 신경 써주세요.”

라고 말하는 것만으로는 부족하다.

회사에서 어떤 보안 기준을 사용할 것인지 정하고,

개발자가 알아야 할 내용을 교육하고,

개발 과정에서 점검할 수 있는 절차를 만들어야 한다.

마찬가지로 배포 과정에서도

“배포할 때 조심하세요.”

라고 말하는 것으로 끝내면 안 된다.

누가 승인할 것인지,

어떤 기준으로 검토할 것인지,

어떤 기록을 남길 것인지

프로세스를 만들어야 한다.

결국 개발자의 보안 수준을 높이는 것도

개발자 개인에게 책임을 전가하는 것이 아니라 회사의 개발 프로세스 자체를 바꾸는 일이라는 생각이 들었다.

10일차를 마치며

10일째가 되니 이제 ISO 27001이 왜 관리체계라고 불리는지 조금씩 알 것 같다.

처음에는 보안이라고 하면

방화벽,

백신,

VPN,

MFA,

취약점 점검 같은 기술적인 부분을 먼저 떠올렸다.

물론 이런 것들도 중요하다.

하지만 그것만으로 끝나는 것이 아니었다.

개발을 누가 하고,

운영을 누가 하고,

배포를 누가 승인하고,

변경을 어떻게 관리하고,

외부에서 누가 접속하며,

그 모든 과정이 어떻게 기록되는지까지 연결되어야 했다.

그리고 작은 회사라서 모든 역할을 완벽하게 나눌 수 없다면,

그 현실을 인정하면서도 승인·검토·기록이라는 통제를 만들어야 한다는 것도 알게 됐다.

10일차가 끝났을 때 머릿속은 여전히 복잡했다.

해야 할 일은 계속 늘어나는 것 같고,

미팅도 계속 이어지고,

확인해야 할 것도 산더미였다.

그런데 한편으로는 조금씩 방향이 명확해지고 있었다.

지금까지는

“우리 회사에 문제가 많다.”

라는 생각이 컸다면,

이제는 조금씩

“그래서 이 문제를 어떤 시스템과 프로세스로 관리해야 하는가?”

를 생각하기 시작했다.

그리고 아마 그게 지금까지의 컨설팅에서 가장 큰 변화였던 것 같다.

보안을 잘해야 한다는 생각에서, 보안이 제대로 작동하도록 시스템을 만들어야 한다는 생각으로 바뀌고 있었다.

ISO 27001 준비 10일차.

아직 갈 길은 멀다.

그런데 이제는 적어도 무엇을 고쳐야 하는지는 조금씩 보이기 시작했다.