새벽 2시, 운영관리자에게 두 통의 보고가 거의 동시에 들어옵니다.
하나는 "결제 서비스가 응답하지 않습니다"(가용성 문제). 다른 하나는 "퇴사한 협력사 직원 계정으로 어젯밤 관리자 콘솔 로그인 기록이 있습니다"(접근통제 문제).
신입 운영자라면 첫 번째 — 눈에 보이는 장애 — 에만 매달릴 수 있습니다. 하지만 노련한 관리자는 둘 다 '보안 사건'의 렌즈로 봅니다. 결제 중단도 누군가의 의도된 공격일 수 있고(가용성도 보안의 일부), 두 번째는 명백한 기밀성·무결성 위협입니다. 회수됐어야 할 권한이 살아 있었다는 것 — 그 한 줄이 사고의 시작입니다.
이 모듈은 보안을 '보안팀만의 어려운 영역'이 아니라, 운영관리자가 매일의 계정·권한·정책 속에서 다뤄야 하는 일로 끌어내립니다. 깊은 암호학·방화벽 설계가 아니라, 운영에 녹이는 보안이 주제입니다.
- 1정보보안 관리의 목적을, 기술 통제가 아니라 "서비스 가치(자산)를 위협으로부터 지키는 것"으로 설명할 수 있다
- 2CIA 3요소(기밀성·무결성·가용성)를 구분하고, 각 요소가 깨진 사례를 운영 상황으로 들 수 있다
- 3최소권한 원칙과 계정 생명주기(생성·변경·회수)·정기 권한 검토의 필요성을 설명할 수 있다
- 4보안 정책·보안 인시던트(침해사고)·보안과 운영의 균형을 운영관리자 관점에서 다룰 수 있다
- 5한국의 ISMS-P 같은 인증이 어떤 맥락에서 요구되는지 일반적 수준에서 이해할 수 있다
보안은 '잠그는 것'이 아니라 '가치를 지키는 것'
정보보안 관리의 목적 — 자산을 위협으로부터
운영관리자에게 보안이 어렵게 느껴지는 이유는, 보안을 **'기능을 잠그고 불편하게 만드는 일'**로 배우기 때문입니다. ITSM의 시선은 다릅니다. 보안은 그 자체가 목적이 아니라, 서비스가 만들어내는 가치(자산)를 위협으로부터 지켜 가용성·신뢰를 유지하는 수단입니다.
여기서 핵심 어휘를 잡고 갑니다.
| 용어 | 뜻 | 운영 예 |
|---|---|---|
| 자산(Asset) | 지킬 가치가 있는 것 | 고객 개인정보, 결제 데이터, 서비스 가용성 |
| 위협(Threat) | 자산에 해를 끼칠 수 있는 요인 | 외부 공격, 내부자 실수, 랜섬웨어, 정전 |
| 취약점(Vulnerability) | 위협이 파고드는 약점 | 회수 안 된 계정, 미적용 패치, 공유된 비밀번호 |
| 위험(Risk) | 위협이 취약점을 통해 자산에 손해를 줄 가능성·영향 | "회수 안 된 관리자 계정으로 고객정보 유출" |
| 통제(Control) | 위험을 줄이는 조치 | 접근통제, 암호화, 백업, 권한 검토 |
정보보안 관리는 결국 **"무엇을(자산), 무엇으로부터(위협), 어디가 약해서(취약점), 얼마나 위험한가(위험)를 보고, 비례하는 통제를 선택·운영하는 일"**입니다. 모든 자산을 똑같이 강하게 잠그는 게 아니라, 위험이 큰 곳에 통제를 집중합니다.
이 모듈은 운영관리자 시야에 맞춰 접근통제·계정·정책·인시던트를 다룹니다. 방화벽 규칙 설계, 침입 탐지 튜닝, 암호 알고리즘 같은 깊은 기술 보안은 networking·infra-ops 트랙의 영역이며, 여기서는 그것들을 '서비스 운영에 어떻게 녹이고 관리하느냐'의 관점으로만 봅니다.
CIA 3요소 — 보안 목표를 세 개의 질문으로
기밀성 · 무결성 · 가용성
정보보안의 목표는 추상적으로 들리지만, 사실 세 개의 구체적인 질문으로 쪼개집니다. 머리글자를 따 CIA라 부릅니다.
- 기밀성(Confidentiality): "허가받은 사람만 볼 수 있는가?" — 정보가 권한 없는 사람에게 노출되지 않게 하는 것.
- 무결성(Integrity): "데이터가 정확하고 위변조되지 않았는가?" — 정보가 의도치 않게 또는 부정하게 바뀌지 않게 하는 것.
- 가용성(Availability): "필요할 때 쓸 수 있는가?" — 권한 있는 사용자가 원할 때 서비스·데이터에 접근할 수 있게 하는 것.
세 가지는 서로 긴장 관계일 수 있다는 점이 운영자에게 중요합니다. 기밀성을 극단으로 올리려 접근을 다 막으면 가용성이 떨어집니다. 셋의 균형점을 자산의 위험에 맞게 잡는 것이 보안 설계입니다.
| 요소 | 보장하려는 것 | 깨졌을 때(운영 사례) | 대표 통제 |
|---|---|---|---|
| 기밀성 | 허가된 사람만 열람 | 내부 문서가 외부 공개 링크로 유출 | 접근통제, 암호화, 권한 분리 |
| 무결성 | 위변조 없는 정확함 | 결제 금액이 중간에 조작됨, 로그가 임의로 삭제됨 | 변경 통제, 무결성 검증(해시), 감사로그 |
| 가용성 | 필요할 때 사용 가능 | 랜섬웨어·정전·DDoS로 서비스 중단 | 백업, 이중화, DR, 용량관리 |
운영관리자에게 가용성은 특히 친숙합니다 — 가용성 저하는 곧 우리가 매일 다루는 인시던트이기 때문입니다. 그래서 "보안은 멀고 어렵다"가 아니라, 이미 하고 있는 가용성 관리가 보안의 한 축임을 알면 보안이 운영의 언어로 들어옵니다.
확대
그림: 보안 목표는 세 개의 구체적 질문(허가된 사람만 보는가·위변조 없는가·필요할 때 쓰는가)으로 쪼개지며, 세 요소는 서로 긴장 관계일 수 있다.
접근통제 — 보안이 운영과 만나는 가장 흔한 접점
최소권한과 계정 생명주기
운영관리자가 보안에서 가장 자주, 직접 다루는 것은 누가 무엇에 접근할 수 있는가 — 접근통제입니다. 화려한 공격 방어보다 앞서, 사고의 상당수는 권한이 잘못 부여되거나 회수되지 않아 일어납니다.
최소권한(least privilege) 원칙: 각 사용자·계정에게 업무에 꼭 필요한 만큼만, 필요한 기간만 권한을 줍니다. 이유는 단순합니다 — 한 계정이 탈취되거나 오용됐을 때, 그 계정이 가진 권한만큼만 피해가 번지기 때문입니다(폭발 반경 최소화). 모두에게 관리자 권한을 주면 어느 계정 하나만 뚫려도 전부 뚫린 셈이 됩니다.
여기에 짝이 되는 개념이 계정 생명주기입니다. 계정은 만들어지고(입사·프로젝트 투입), 바뀌고(부서·역할 변경), 사라져야(퇴사·프로젝트 종료) 합니다. 이 생명주기가 끊기면 — 특히 회수가 빠지면 — 위험이 누적됩니다.
| 단계 | 해야 할 일 | 빠지면 생기는 위험 |
|---|---|---|
| 생성(입사·투입) | 역할에 맞는 최소 권한만 부여, 신청·승인 기록 | 과도 권한으로 시작, 누가 줬는지 불명확 |
| 변경(역할 전환) | 이전 권한 회수 + 새 역할 권한 부여 | 권한 누적(privilege creep) — 옛 권한이 계속 살아 있음 |
| 회수(퇴사·종료) | 즉시 비활성화·삭제, 공유 비밀번호 교체 | 유령 계정으로 무단 접근(시나리오의 그 사건) |
| 정기 검토 | 주기적으로 "이 권한이 아직 필요한가" 점검 | 시간이 지나며 권한이 현실과 어긋남 |
특히 한국 SI/SM 현장처럼 협력사·하도급 인력이 드나드는 환경에서는 계정 회수가 더 자주, 더 분명하게 깨집니다. "프로젝트 끝났는데 계정이 살아 있다"는 가장 흔하고 위험한 취약점이며, 운영관리자가 직접 관리하는 영역입니다.
확대
그림: 계정은 생성·변경·회수·검토를 도는 순환이며, 특히 "회수"가 끊기면 유령 계정이라는 가장 흔한 취약점이 쌓인다 — 외부 계정엔 만료일을 강제해 잊혀도 자동으로 닫히게 한다.
보안 정책과 침해사고 — 그리고 균형
정책 · 보안 인시던트 · 보안과 운영의 균형
**보안 정책(security policy)**은 "우리 조직에서 정보를 어떻게 다룰지"에 대한 합의된 규칙입니다 — 비밀번호 규칙, 접근 권한 부여·검토 절차, 외부 반출 규칙, 사고 발생 시 대응 절차 등. 정책의 가치는 문서가 아니라 일관성에 있습니다. 누가 판단해도 같은 기준으로 권한을 주고, 같은 절차로 사고에 대응하게 만드는 것이죠. 앞 모듈들에서 본 '개인기 임기응변 → 반복 가능한 체계'의 보안판입니다.
**보안 인시던트(침해사고)**는 CIA 중 하나 이상이 침해됐거나 침해될 위협이 현실화된 사건입니다. 일반 인시던트와 절차가 겹치지만(빠른 차단·복구), 보안 고유의 단계가 더해집니다.
- 외부 공격만이 아니라 내부자 실수·오설정도 침해사고입니다(예: 내부 문서를 외부 공개로 잘못 설정).
- 증거 보존: 무슨 일이 일어났는지 추적하려면 로그·기록을 함부로 지우지 않습니다.
- 영향 평가와 통지: 개인정보가 관련되면 법·계약상 통지 의무가 생길 수 있습니다. 운영관리자가 단독으로 "별일 아님" 판단을 내리면 안 되는 이유입니다.
- 재발 방지: 일반 인시던트와 마찬가지로 근본 원인(예: 회수 안 된 계정)을 문제관리로 넘겨 제거합니다.
마지막으로 보안과 운영의 균형입니다. 보안을 극단으로 올리면 가용성·사용성이 떨어지고, 사용자는 통제를 우회하는 길(섀도우 IT, 비밀번호 공유)을 만들어 오히려 더 위험해집니다. 반대로 통제가 없으면 사고가 가치를 무너뜨립니다. 그래서 통제는 위험에 비례해야 합니다 — 고객 결제 데이터에는 강한 통제, 사내 점심 메뉴 게시판에는 가벼운 통제. 운영관리자는 보안팀의 정책과 운영 현실 사이의 접점에 서 있습니다.
직접 해보기 — CIA 표와 권한 검토 체크리스트 만들기
가상의 '사내 결제 서비스'를 대상으로, 아래 표를 직접 채워 보세요. 자산이 무엇인지부터 정하고, CIA 각 요소에 대해 (1) 무엇이 위협이고 (2) 어떤 통제로 막을지 적습니다. 예시 답안은 ObserveBlock에 있습니다.
[CIA 3요소 적용 표 — 사내 결제 서비스]
자산: ____________________________
| 요소 | 이 서비스에서 보장할 것 | 대표 위협 | 적용할 통제 |
|----------|------------------------|-----------|-------------|
| 기밀성 | (예: 결제·고객 정보 비노출) | | |
| 무결성 | (예: 결제 금액 위변조 없음) | | |
| 가용성 | (예: 결제 시점 항상 가능) | | |
핵심은 세 요소를 따로따로 보는 연습입니다. 같은 서비스라도 기밀성·무결성·가용성에 대한 위협과 통제가 서로 다릅니다.
자산을 정하고 → CIA별로 위협·통제를 채운다아래 접근권한 검토 체크리스트를 기준으로, 운영 중인 시스템(또는 가상의 팀)의 계정·권한을 점검해 보세요. '아니오'가 나오는 항목이 곧 취약점입니다.
[접근권한 검토 체크리스트]
계정 생명주기
[ ] 퇴사자·프로젝트 종료자의 계정이 모두 비활성화/삭제되었는가
[ ] 역할이 바뀐 사람의 '이전 권한'이 회수되었는가
[ ] 공유 계정/공용 비밀번호를 사용하는 곳이 있는가 (있다면 제거 대상)
[ ] 협력사·외부 인력 계정에 만료일(종료일)이 설정되어 있는가
최소권한
[ ] 각 계정이 '업무에 필요한 만큼만' 권한을 갖고 있는가
[ ] 관리자(root/admin) 권한 보유자가 꼭 필요한 인원으로 한정되는가
[ ] 권한 누적(privilege creep)이 의심되는 계정이 있는가
절차·기록
[ ] 권한 부여·변경에 신청·승인 기록이 남는가
[ ] 정기 권한 검토 주기가 정해져 있고 실제로 수행되는가
[ ] 중요 시스템의 접근·변경 로그(감사로그)가 보존되는가
현재 계정·권한을 항목별로 점검한다- CIA 표 예시 — 자산: "결제 거래 데이터와 결제 서비스 가용성"
- 기밀성: 보장=고객/카드정보 비노출 / 위협=계정 탈취·내부 유출 / 통제=접근통제·암호화·권한 분리
- 무결성: 보장=결제 금액·내역 위변조 없음 / 위협=중간 조작·로그 임의 삭제 / 통제=변경 통제·감사로그·무결성 검증
- 가용성: 보장=결제 시점에 항상 응답 / 위협=DDoS·정전·과부하 / 통제=이중화·백업·DR·용량관리
- 체크리스트에서 "아니오"가 나온 항목 = 취약점. 특히 회수 누락·공유 비밀번호·권한 누적은 운영관리자가 즉시 조치할 수 있는 영역
- 핵심 감각: CIA는 따로 보면 위협·통제가 다르고, 접근통제는 화려한 방어보다 "계정 정리"에서 더 많은 위험이 줄어든다
현장에서 자주 보는 함정
증상: 정기 보안 점검·인증 심사는 통과했고 방화벽·백신도 최신입니다. 그런데 실제 침해사고는 외부의 정교한 공격이 아니라, 반년 전 떠난 협력사 직원의 살아 있는 관리자 계정으로 누군가 로그인하면서 시작됐습니다.
원인: 보안을 '도구·인증서'로만 보고, 계정 생명주기라는 운영 프로세스를 빠뜨렸습니다. 입사·투입 때 권한은 잘 줬지만(생성), 종료 때 회수(삭제·비활성화)는 누구의 일도 아니었습니다. 점검은 '시스템 설정'을 봤지 '누가 무엇에 접근 가능한가'의 실태를 보지 않았습니다. 화려한 통제 뒤에 가장 기본적인 취약점이 방치된 전형입니다.
해결 방향:
- 계정 회수를 퇴사·종료 프로세스의 필수 단계로 못박고 책임자를 지정한다(인사·운영 연계).
- 정기 권한 검토를 주기적으로 수행해, 현실과 어긋난 권한·유령 계정을 걷어낸다.
- 협력사·외부 계정에는 만료일을 강제해, 잊혀도 자동으로 닫히게 한다.
- 공유 계정·공용 비밀번호를 제거하고, 모든 권한 부여·변경에 신청·승인 기록을 남겨 추적 가능하게 한다.
보안 사고의 다수는 '뚫린 것'이 아니라 '닫지 않은 것'에서 옵니다. 운영관리자의 보안은 거창한 방어가 아니라, 이 닫는 일을 빠짐없이 하는 데서 출발합니다.
심화 — 인증서 뒤의 보안: 증적, 우회, 그리고 예외의 상설화
심화: 통제가 서류가 되는 세 가지 경로
보안 관리 체계를 배우고 현장에 가면, 문서상 통제와 실제 보안 수준이 따로 노는 조직을 자주 만납니다. 이 괴리는 게으름 때문이 아니라 구조적인 힘 때문에 생기며, 그 힘의 방향을 알아야 관리자가 개입할 지점이 보입니다.
- 심사 대응이 직업이 되는 순간: 인증 심사가 다가오면 TF가 꾸려져 몇 주간 증적을 소급 생산하고, 심사가 끝나면 통제가 원래대로 풀리는 조직이 있습니다. 이때 인증서는 보안 수준의 증거가 아니라 증적 생산 능력의 증거입니다. 진단 질문은 간단합니다 — "심사 없는 달에도 권한 검토 기록이 같은 품질로 쌓이는가." 심사 시즌에만 기록이 두꺼워지는 조직은 인증과 보안이 분리된 상태입니다.
- 지침 준수형 통제와 우회 행동: 위험에 비례하지 않는 일괄 통제는 반드시 우회를 낳습니다. USB를 전면 봉인하면 파일은 개인 메일과 메신저로 나가고(통제 밖 경로로 위험이 이동), 비밀번호를 90일마다 바꾸게 강제하면 뒷자리 숫자만 올라갑니다. 통제의 실효성은 준수율이 아니라 우회 행동의 양으로 측정해야 합니다 — 우회가 관측되면 사용자를 탓하기 전에 통제 설계가 업무 현실과 충돌하고 있다는 신호로 읽는 것이 관리자의 역할입니다.
- 예외는 쉽고 종료는 어렵다: 보안 예외(방화벽 오픈, 망간 접근 허용)는 신청 한 장이면 열리지만, 닫는 쪽은 "업무 영향 검토 + 민원 리스크"를 감수해야 합니다. 이 비대칭 비용 때문에 예외는 쌓이기만 하고, "임시"라는 딱지를 단 채 몇 년을 삽니다. 예외 건수의 총량과 평균 나이를 지표로 보는 조직은 드물지만, 침해사고의 통로는 대부분 이 오래된 예외들입니다.
- 규모별 현실: 보안 전담이 전산 담당의 겸직 0.5명인 중소기업에서 대기업 체계를 흉내 내면 전부가 서류가 됩니다. 이 규모에서는 통제를 세 가지로 좁히는 것이 정직합니다 — 계정 회수, 백업(복원 검증 포함), 패치. 반대로 대기업은 보안팀(차단 실적)과 운영팀(가용성)의 인센티브가 충돌하는 구조 자체를 관리해야 하며, 그 접점에 선 것이 운영관리자입니다.
상황: 망분리 정책상 개발망에서 운영망 직접 접근은 금지된 조직입니다. 4년 전 데이터 이관 프로젝트 때 "2주간 한시 허용" 조건으로 개발망→운영 DB 구간 방화벽 예외가 승인됐습니다. 프로젝트는 끝났지만 "배치 결과를 개발망에서 바로 확인하면 편하다"는 이유로 예외는 남았고, 연 1회 보안 검토 때마다 담당 부서가 "업무상 필요 지속" 한 줄로 연장했습니다. 올해 개발 PC 한 대가 랜섬웨어에 감염되자, 악성코드는 이 열린 경로로 운영 DB 서버에 도달했고 운영 데이터 일부가 암호화됐습니다. 복구는 백업으로 했지만(인시던트 관리 절차로 대응), 침해 경로 보고서의 첫 줄은 방화벽 취약점이 아니라 "승인된 예외"였습니다.
원인: 예외 프로세스에 종료 메커니즘이 없었습니다. 연장은 대장에 한 줄 적으면 끝나지만, 차단하려면 영향 검토를 하고 현업 반발을 감당해야 합니다 — 아무도 그 비용을 질 이유가 없으니 연장이 기본값이 됐습니다. 더 깊게는, 예외를 건별로만 승인하고 총량을 보는 사람이 없었습니다. 한 건 한 건은 다 사정이 있어 보이지만, 누적된 전체가 망분리라는 통제 자체를 무력화하고 있다는 사실은 어느 결재선에도 보이지 않았습니다.
진단: 사고 후 예외 승인 대장을 전수 조사했습니다 — 유효 예외 187건 중 최초 승인 사유(프로젝트)가 이미 소멸한 건이 143건, 만료일이 지난 채 형식 연장된 건이 171건. 방화벽 정책을 실제 트래픽과 대조하니 최근 90일간 통신이 한 건도 없는 예외 정책이 38%였습니다 — 쓰지도 않으면서 열려만 있는 문이 세 개 중 하나였다는 뜻입니다. 예외 대장의 "평균 나이"는 2.7년이었고, 종료(차단) 처리된 예외는 4년간 6건뿐이었습니다.
해결: 예외의 비대칭 비용을 뒤집었습니다. ① 모든 예외에 만료일과 자동 차단을 강제 — 연장하려면 신규 신청과 동일한 심사(사유·기간·범위)를 다시 통과해야 하고, "지속 필요" 한 줄 연장은 시스템에서 불가능하게 변경. ② 예외마다 **소유자(신청 부서장)**를 지정해, 만료 차단으로 생기는 업무 영향의 설명 책임을 보안팀이 아니라 소유자가 지게 함. ③ 분기마다 실트래픽 기준으로 무통신 예외를 일괄 정리하고, 예외 총량과 평균 나이를 월간 보안 보고의 고정 지표로 추가. 6개월 뒤 유효 예외는 187건에서 41건으로 줄었고, 남은 41건은 전부 사유·기간·소유자가 살아 있는 예외였습니다. 통제의 강도는 규칙의 엄격함이 아니라 예외가 죽는 속도로 결정됩니다.
한국의 기업·공공기관에서 일정 규모 이상이거나 개인정보를 다루는 서비스를 운영하면, ISMS-P 같은 정보보호·개인정보보호 관리체계 인증을 요구받는 맥락을 만나게 됩니다. 핵심은 인증의 세부 항목을 외우는 것이 아니라, 이런 인증이 결국 이 모듈에서 다룬 것들 — 접근통제·계정관리·정책·사고 대응·기록 — 을 "체계적으로 하고 있는가, 그리고 증명할 수 있는가"를 본다는 점을 이해하는 것입니다.
그래서 운영관리자에게 인증 대응은 별도의 특수 업무가 아니라, 평소의 운영을 기록과 함께 일관되게 하는 일의 연장입니다. 권한 부여에 승인 기록이 남고, 퇴사자 계정 회수가 절차로 돌고, 사고 대응이 문서로 정리되어 있으면 — 인증은 그 운영의 증거를 보여주는 일이 됩니다. 반대로 평소에 기록 없이 임기응변으로 굴리면, 인증 시즌마다 없는 증거를 만드느라 고생합니다.
정확한 인증 항목·적용 대상·심사 기준은 시기와 기관에 따라 달라지므로, 단정해서 외우기보다 소관 규정과 최신 기준 문서를 확인하는 습관이 더 안전합니다. 운영관리자가 갖춰야 할 것은 인증 지식 자체보다, "우리 운영이 보안 관점에서 일관되고 기록되어 있는가"를 스스로 점검하는 눈입니다.
실전 랩으로 손에 익히기: 정보보안 관리 실습 — CIA 트레이드오프·접근통제·보안사고 대응을 설계합니다.
관련 모듈로 더 깊이:
- 공급자·협력사 관리 — 외부 공급자·협력사의 보안과 접근 권한까지 계약·점검으로 통제하는 법
- 인시던트 관리 — 보안 사고가 터졌을 때 인시던트 절차로 탐지·대응·복구하는 흐름
- 변경 관리(변경 활성화) — 권한·설정 변경을 승인 기록과 함께 안전하게 반영하는 변경 관리
다음 모듈에서는 이 운영 책임이 외부로 확장되는 지점 — 공급자·협력사 관리, 즉 우리가 직접 통제하지 못하는 외부 인력·업체의 작업 품질과 보안을 어떻게 계약·점검·관리하는지를 다룹니다.