보안 관리 체계

보안은 오랫동안 물건을 사는 문제로 다뤄졌습니다. 방화벽을 들이고 백신을 깔고 접속 기록을 모아 두는 장비를 붙이면 할 일이 끝난 것으로 봤습니다. 예산 항목도 그렇게 잡혔습니다. 보안에 얼마를 썼느냐는 질문에 도구 값을 더해 답하면 됐고, 사고가 나면 더 비싼 도구를 사는 것이 다음 대책이었습니다.

그런데 실제로 터지는 사고는 대체로 장비가 못 막는 자리에서 났습니다. 누군가 급해서 운영 데이터베이스 계정을 팀 채널에 붙여 넣고 지우지 않았다거나, 외주 개발자에게 잠깐 열어 준 권한이 계약이 끝난 뒤에도 그대로 살아 있다거나, 대표 이름으로 온 가짜 메일에 재무 담당자가 첨부 파일을 열었다거나 하는 일들입니다. 어느 쪽도 도구가 고장 나서 생긴 일이 아닙니다. 사람이 하는 일과 그 일을 확인하는 절차가 정해져 있지 않아서 생긴 일입니다.

페이지덱이 이 사실을 확인한 자리는 기업 고객의 보안 질문지였습니다. 수아가 받아 온 표에는 퇴사자의 계정을 언제 잠그느냐는 항목이 있었고, 태오가 답을 적으려다 멈췄습니다. 회사에 정해진 답이 없었습니다. 그 자리에서 계정 목록을 뽑아 보니 석 달 전에 나간 디자이너의 계정이 살아 있었고, 두 달 전에 계약이 끝난 외주 개발자의 저장소 접근도 그대로였습니다. 잠그는 방법을 몰라서가 아니었습니다. 잠글 사람이 정해져 있지 않았고, 잠갔는지 확인하는 날도 정해져 있지 않았습니다.

보안 관리 체계는 이 빈자리를 메우려고 붙은 이름입니다. 무엇을 지킬지, 누가 언제 확인할지, 어긋났을 때 누가 고칠지를 미리 정해 두고 정해진 대로 돌아가는지를 주기적으로 확인합니다. 좋은 금고를 샀는지보다 열쇠를 몇 개 만들었고 그중 몇 개가 이미 나간 사람 손에 있는지가 실제 사고를 가르기 때문입니다. 기술이 아니라 운영이라는 점이 이 일의 성격입니다. 그래서 시작하는 방법도 도구를 고르는 것이 아니라 지금 무엇이 정해져 있지 않은지를 적어 보는 것입니다. 페이지덱이 질문지 한 장에서 찾아낸 빈칸은 열일곱 개였고, 그중 열두 개는 규칙이 틀려서가 아니라 규칙 자체가 없어서 비어 있었습니다.

이 이름 아래 묶인 용어는 다섯 갈래입니다. 지킬 대상을 세어 두는 것이 관리이고, 지킬 방법을 문장으로 적어 둔 것이 규정이고, 적어 둔 대로 돌리는 일이 절차이고, 그래도 뚫렸을 때를 맡는 것이 대응이고, 이 넷 전체가 어느 쪽을 향하는지를 정하는 것이 원칙입니다.

관리는 대상을 세는 갈래입니다. 자산 목록은 지켜야 할 시스템과 데이터를 한 표에 모아 둔 것입니다. 서버와 데이터베이스만이 아니라 회사가 돈을 내고 쓰는 외부 도구, 그 도구에 들어 있는 데이터, 구성원이 쓰는 노트북까지 들어갑니다. 항목마다 누가 책임지는지와 어떤 데이터가 들어 있는지를 적어 둡니다. 이 표가 먼저 있어야 나머지가 성립합니다. 목록에 없는 시스템은 권한을 점검할 때도 빠지고, 사고가 났을 때 확인할 곳에서도 빠집니다. 페이지덱에서 외주 개발자의 저장소 접근이 남아 있었던 이유도 그 저장소가 아무 표에도 없었기 때문입니다. 표를 만들 때 가장 자주 빠지는 것은 각자 알아서 붙인 도구입니다. 팀 하나가 법인카드로 결제해 쓰기 시작한 설문 도구에 고객 이메일이 몇천 건 쌓여 있는 식인데, 이런 것은 결제 내역을 훑어야 드러납니다.

규정은 방법을 문장으로 고정하는 갈래입니다. 보안 정책은 비밀번호를 어떻게 만들고 관리자 권한을 누가 승인하며 회사 데이터를 개인 기기에 어디까지 둘 수 있는지 같은 규칙을 문서로 적어 둔 것입니다. 적는 일 자체는 어렵지 않고, 어려운 것은 지킬 수 있는 선에서 적는 일입니다. 현실보다 두 단계 엄한 규칙을 적어 두면 전원이 우회하는 길을 찾고, 그때부터 문서는 실제로 돌아가는 것과 다른 이야기를 하기 시작합니다.

절차는 적어 둔 것이 지켜지는지 실제로 돌리는 갈래입니다. 셋입니다.

1. 접근 권한 점검 — 누가 무엇에 접근할 수 있는지를 주기적으로 뽑아 보고 필요 없어진 권한을 회수하는 일입니다. 분기마다 한 번이 흔한 주기입니다. 사람이 아니라 날짜로 거는 것이 핵심인데, 권한은 줄 때는 요청이 있어 티가 나지만 필요 없어질 때는 아무도 알려 주지 않기 때문입니다. 잠깐만 열어 달라는 요청은 대개 잠깐으로 끝나지 않습니다.
2. 보안 교육 — 구성원에게 지켜야 할 수칙을 가르치는 활동입니다. 한 해에 한 번 몰아서 듣는 형태가 가장 흔하고 가장 효과가 적습니다. 새로 들어온 사람에게 첫 주에 우리 회사에서 고객 데이터를 어디까지 열어 볼 수 있는지 알려 주는 쪽이, 전원에게 일반적인 보안 상식을 한 시간 들려주는 쪽보다 실제로 사고를 줄입니다.
3. 피싱 모의 훈련 — 진짜처럼 보이는 가짜 메일을 회사 안에 보내 누가 링크를 누르는지 세어 보는 훈련입니다. 목적은 누른 사람을 찾아내는 것이 아니라 비율을 재고 그 비율을 낮추는 것입니다. 누른 사람의 이름을 공유하면 다음 훈련부터 아무도 신고하지 않게 되고, 신고가 끊기면 진짜 메일이 왔을 때 아는 사람이 없어집니다.

대응은 뚫린 뒤를 맡는 갈래입니다. 침해 사고 대응 계획은 사고가 났을 때 누가 무엇을 어떤 순서로 하는지 미리 적어 둔 문서입니다. 사고를 판단할 사람, 서비스를 멈출 권한을 가진 사람, 고객과 감독 기관에 알릴 사람을 이름으로 적어 두고, 알리기까지 몇 시간이 걸리는지를 숫자로 정합니다. 시한을 숫자로 적는 이유는 법이 통지 기한을 정해 두는 경우가 많기 때문입니다. 사고가 터진 뒤에 누가 결정하느냐를 논의하기 시작하면 그 논의 시간이 곧 기한을 잡아먹습니다.

원칙은 앞의 넷이 어느 쪽으로 움직일지를 정하는 갈래입니다. 제로 트러스트는 사내망 안에 있다는 이유만으로 믿어 주지 않고 접근할 때마다 누구인지와 그 권한이 지금도 유효한지를 확인하는 방식입니다. 예전 방식은 담장을 하나 두르고 그 안을 안전한 곳으로 취급하는 형태였습니다. 사무실 밖에서 일하고 회사 데이터가 여러 외부 서비스에 나뉘어 있는 상황에서는 담장 안이라는 자리가 없어져서, 기준을 위치에서 신원으로 옮긴 것입니다. 앞의 네 갈래가 이 원칙 위에서 다시 읽힙니다. 자산 목록은 담장이 아니라 데이터 기준으로 묶이고, 권한 점검은 부서가 아니라 사람 단위로 걸립니다.

다섯 갈래는 한 바퀴로 이어집니다. 자산 목록이 대상을 세고, 보안 정책이 대상마다 규칙을 붙이고, 점검과 교육과 훈련이 그 규칙을 사람에게 닿게 하고, 대응 계획이 그래도 뚫린 날을 맡고, 사고에서 배운 것이 다시 정책과 목록으로 돌아옵니다. 이 바퀴가 돌고 있다는 것을 밖에 보이는 일은 보안 인증이 맡습니다.

"그 권한은 지난 분기 점검 때 회수됐어야 하는데요. 애초에 목록에 없었습니다."

권한 자체보다 그 시스템이 자산 목록에서 빠져 있었던 것이 더 큰 문제라는 지적입니다.

"이건 정책에 없는 상황이네요. 지금 정하고 다음 개정에 넣죠."

규칙이 없을 때 그 자리에서 판단하되 그 판단을 문서로 되돌려 놓겠다는 말입니다.

"이번 훈련 클릭률이 18퍼센트인데 신고율은 그대로예요."

가짜 메일을 누른 비율은 높은데 이상하다고 알린 비율이 안 올랐으니 교육의 방향을 바꾸자는 뜻입니다.

퇴사자 계정 건 이후로 페이지덱은 세 가지를 정했습니다. 사람이 나가는 날 계정을 잠그는 일을 입사와 퇴사 절차에 붙여 놓고, 분기마다 규원이 전체 권한 목록을 뽑아 태오와 함께 훑고, 새 외부 도구를 붙일 때 자산 목록에 줄을 추가하지 않으면 결제를 승인하지 않기로 했습니다. 세 가지 모두 도구를 새로 사서 한 일이 아니라 이미 하던 일에 확인하는 날짜와 담당자를 붙인 것입니다.

가장 오래 걸린 쪽은 사람이 하는 부분이었습니다. 첫 피싱 모의 훈련에서 45명 중 11명이 링크를 눌렀고, 그중 이상하다고 알린 사람은 한 명이었습니다. 규원은 누가 눌렀는지를 공개하지 않고 비율만 공유했습니다. 두 번째 훈련에서 클릭은 6명으로 줄었고 신고는 9명으로 늘었습니다. 태오가 그 숫자를 보고 한 말은 클릭이 줄어서가 아니라 신고가 늘어서 다행이라는 것이었습니다. 진짜 메일은 언제나 누군가 한 명은 누르고, 그다음에 무슨 일이 일어나는지는 알리는 사람이 있느냐가 정하기 때문입니다.

도구를 사면 갖춰진다고 보는 경우가 가장 많습니다. 보안 제품을 파는 쪽이 대개 한 화면에서 다 관리된다고 설명하니 그렇게 읽히기 쉽습니다. 그러나 도구가 해 주는 일은 현황을 보여 주는 것까지입니다. 권한 목록을 뽑아 주는 도구는 있어도 필요 없어진 권한을 판단해 회수하는 일은 사람이 하고, 그 사람과 날짜가 정해져 있지 않으면 목록은 매분기 같은 모양으로 쌓이기만 합니다. 이 오해를 그대로 두면 지출은 늘었는데 고객 질문지의 빈칸은 그대로인 상태가 됩니다. 언제 점검했는지, 누가 확인했는지, 무엇을 찾아 어떻게 고쳤는지를 묻는 항목에는 도구 이름을 적을 수 없기 때문입니다.

규칙을 많이 적어 둘수록 안전해진다고 보는 것도 흔합니다. 문서가 두꺼우면 준비가 잘된 것처럼 보이고, 심사나 질문지를 앞두고는 특히 그렇게 하고 싶어집니다. 하지만 지킬 수 없는 규칙은 지켜지지 않는 데서 끝나지 않고 우회하는 습관을 만듭니다. 운영 데이터 조회에 매번 두 사람의 승인을 받게 해 두면 급한 장애 때마다 승인을 건너뛰는 일이 생기고, 몇 번 반복되면 그 조항은 없는 것과 같아집니다. 그렇게 되면 문서와 현실이 갈라져서 무엇이 실제 규칙인지 아무도 모르게 되고, 지켰다는 기록을 만들 방법도 사라집니다. 적을 때의 기준은 엄격함이 아니라 지켜지는지 확인할 수 있느냐입니다. 규칙을 느슨하게 적는 대신 어긴 경우를 예외로 기록해 두는 방법도 있습니다. 급해서 승인을 건너뛰었다면 그 사실과 이유를 남기고 나중에 모아서 검토하는 쪽이, 아무도 지키지 않는 조항을 문서에 그대로 두는 것보다 낫습니다.