보안 포탈 설계 (2) 물어보고 기다리는 절차를 만들었습니다

당사자에게 묻고 답을 받는 단계를 어떻게 만들었는지 다룹니다. 시리즈의 다른 글 보기

안녕하세요. 오픈소프트랩 개발팀입니다.

지난 편에서 보안 이벤트가 업무 티켓과 다른 지점을 썼습니다. 그중 하나가 완료 조건이었습니다. 담당자가 처리해도 끝나지 않고, 당사자가 답해야 끝나는 건이 있었습니다.

이번 편은 그 "물어보는 단계"를 만든 이야기입니다.

메일 한 통이면 될 줄 알았습니다

처음 설계는 간단했습니다.

대상자에게 메일을 보내고, 답을 받아서 기록한다. 탐지 시스템이 대상자 아이디와 이메일까지 넘겨주니 보낼 곳은 이미 알고 있었습니다.

만들고 나서 며칠 만에 막혔습니다.

답을 받을 방법이 없었습니다

첫 번째 문제는 대상자가 시스템을 쓰는 사람이 아니라는 것이었습니다.

보안 이벤트에 걸리는 사람은 보안 담당자가 아닙니다. 영업이고 개발자고 협력사 직원입니다. 이 사람들은 보안 포탈 계정이 없습니다. 있어도 써본 적이 없습니다.

메일에 "포탈에 로그인해서 답변하세요"라고 쓰면 어떻게 될까요. 계정을 찾고, 비밀번호를 재설정하고, 메뉴를 찾아야 합니다. 그 과정을 넘어서까지 답할 사람은 많지 않습니다.

그래서 로그인을 요구하지 않기로 했습니다. 메일에 담긴 링크를 누르면 그 건에 대해서만 답을 쓸 수 있는 화면이 열립니다. 링크에 담긴 토큰이 그 사람이 그 건에 답할 자격을 증명합니다.

계정 체계를 건드리지 않고 답을 받을 수 있게 된 지점입니다.

근거를 같이 보여줘야 했습니다

두 번째 문제는 질문의 모양이었습니다.

귀하의 행위가 정책에 위반되어 소명을 요청합니다라고만 쓰면 받는 사람은 무슨 일인지 모릅니다. 언제 무엇을 했다는 건지 알 수 없으니 답을 쓸 수가 없습니다.

탐지 시스템이 넘겨주는 데이터에 답이 있었습니다.

• 위반 일시
• 상세 로그 — 어떤 파일을 어디로 보냈는지, 어떤 표현이 포함됐는지

이걸 질문과 함께 보여주기로 했습니다. 무엇을 근거로 묻는지 알려주지 않으면 답이 올 수 없습니다.

그런데 여기서 균형이 필요했습니다. 근거를 다 보여주면 탐지 규칙이 드러납니다. 어떤 조건에 걸리는지 알면 피하는 방법도 알게 됩니다. 지금은 무엇을 했는지는 보여주고, 어떤 규칙에 어떻게 걸렸는지는 보여주지 않는 선에서 자르고 있습니다.

안 오는 경우를 전부 다뤄야 했습니다

세 번째가 가장 오래 걸렸습니다.

메일을 보내는 것까지는 쉽습니다. 문제는 답이 안 올 때입니다. 답이 안 오면 이 건은 영원히 안 끝납니다.

처음 상태는 두 개였습니다. 요청했거나 끝났거나. 운영하면서 다섯 개가 더 생겼습니다.

질문이 나가는 경로는 두 가지입니다. 탐지 데이터가 정해진 조건에 맞으면 자동으로 나가고, 담당자가 필요하다고 판단하면 직접 보냅니다. 어느 쪽으로 나갔든 그다음 상태 흐름은 같습니다.

아래 두 개가 이 절차의 성격을 보여줍니다.

기간 만료는 요청할 때 기한을 같이 정하기 때문에 생깁니다. 기한 없이 두면 담당자는 언제까지 기다려야 할지 모르고, 대상자는 급할 게 없습니다. 기한을 넣으니 둘 다 기준이 생겼습니다.

회수는 반대 방향입니다. 담당자가 다른 경로로 사실을 확인해서 사안을 먼저 닫는 경우가 있습니다. 그때 질문이 남아 있으면 대상자는 이미 끝난 일에 답을 씁니다. 헛수고를 시키는 셈이고, 답이 들어와도 처리할 데가 없습니다. 그래서 사안이 중간에 종료되면 미응답 질문은 거둬들이게 했습니다.

완료를 막아야 했습니다

여기까지 만들고 나서 구멍이 하나 발견됐습니다.

담당자가 질문을 보내놓고 답을 기다리지 않은 채 사안을 완료할 수 있었습니다. 시스템 입장에서는 담당자가 완료 버튼을 누른 것이니 막을 이유가 없었습니다.

그런데 그러면 앞 편에서 말한 완료 조건이 무너집니다. 당사자가 답해야 끝나는 건인데 답 없이 끝난 기록이 남습니다. 나중에 감사에서 "이 건은 어떻게 판단했나" 물으면 근거가 없습니다.

그래서 답이 오기 전에는 최종 완료로 갈 수 없게 막았습니다. 끝내야 한다면 질문을 회수하고 끝내야 합니다. 회수했다는 기록이 남으니 나중에 "왜 답 없이 끝냈나"에 답할 수 있습니다.

얻은 것과 포기한 것

얻은 것 — 판단 근거가 남습니다. 누가 무엇을 물었고 당사자가 뭐라고 답했는지, 답이 없었다면 어떻게 처리했는지가 사안에 붙어 있습니다. 감사 때 따로 모을 필요가 없습니다.

포기한 것 — 절차가 느려졌습니다. 예전에는 담당자가 확인하고 닫으면 끝이었는데 이제 사람의 답을 기다립니다. 며칠이 걸립니다. 그리고 관리할 상태가 일곱 개로 늘어서 운영자가 익혀야 할 것도 늘었습니다.

빠른 종료와 설명 가능한 종료 중에 후자를 골랐습니다. 보안 업무에서 나중에 설명하지 못하는 처리는 안 한 것과 비슷하다고 봤습니다.

기한을 며칠로 줘야 하는가

지금 정하지 못한 부분입니다.

기한을 짧게 잡으면 만료가 늘어납니다. 대상자가 휴가 중이거나 외근이면 못 봅니다. 길게 잡으면 사안이 오래 열려 있고, 그동안 탐지 데이터는 계속 쌓입니다.

지금은 조직이 정하게 열어뒀습니다. 업무 성격에 따라 적정선이 다를 것 같아서입니다. 다만 처음 도입하는 곳은 기준이 없으니 저희가 주는 초기값을 그대로 씁니다. 그 값이 맞는지는 아직 모릅니다.

만료된 건을 어떻게 볼 것인지도 남아 있습니다. 답이 없는 것을 부인으로 볼지, 미확인으로 볼지, 아니면 다시 물어볼지는 조직의 정책 영역이라 저희가 정하기 어렵습니다. 지금은 만료라는 사실만 남기고 판단은 담당자에게 넘기고 있는데, 재요청을 몇 번까지 허용할지 같은 것은 운영 사례를 더 보고 정하려 합니다.

다음 편에서는 이 제품을 다시 만들면서 겪은 일을 다룹니다.

오픈소프트랩 개발팀이 작성합니다. 보안 운영 포탈과 생성형 AI 사용 통제를 만들고 있습니다.