새벽 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는 따로 보면 위협·통제가 다르고, 접근통제는 화려한 방어보다 "계정 정리"에서 더 많은 위험이 줄어든다
현장에서 자주 보는 함정
증상: 정기 보안 점검·인증 심사는 통과했고 방화벽·백신도 최신입니다. 그런데 실제 침해사고는 외부의 정교한 공격이 아니라, 반년 전 떠난 협력사 직원의 살아 있는 관리자 계정으로 누군가 로그인하면서 시작됐습니다.
원인: 보안을 '도구·인증서'로만 보고, 계정 생명주기라는 운영 프로세스를 빠뜨렸습니다. 입사·투입 때 권한은 잘 줬지만(생성), 종료 때 회수(삭제·비활성화)는 누구의 일도 아니었습니다. 점검은 '시스템 설정'을 봤지 '누가 무엇에 접근 가능한가'의 실태를 보지 않았습니다. 화려한 통제 뒤에 가장 기본적인 취약점이 방치된 전형입니다.
해결 방향:
- 계정 회수를 퇴사·종료 프로세스의 필수 단계로 못박고 책임자를 지정한다(인사·운영 연계).
- 정기 권한 검토를 주기적으로 수행해, 현실과 어긋난 권한·유령 계정을 걷어낸다.
- 협력사·외부 계정에는 만료일을 강제해, 잊혀도 자동으로 닫히게 한다.
- 공유 계정·공용 비밀번호를 제거하고, 모든 권한 부여·변경에 신청·승인 기록을 남겨 추적 가능하게 한다.
보안 사고의 다수는 '뚫린 것'이 아니라 '닫지 않은 것'에서 옵니다. 운영관리자의 보안은 거창한 방어가 아니라, 이 닫는 일을 빠짐없이 하는 데서 출발합니다.
한국의 기업·공공기관에서 일정 규모 이상이거나 개인정보를 다루는 서비스를 운영하면, ISMS-P 같은 정보보호·개인정보보호 관리체계 인증을 요구받는 맥락을 만나게 됩니다. 핵심은 인증의 세부 항목을 외우는 것이 아니라, 이런 인증이 결국 이 모듈에서 다룬 것들 — 접근통제·계정관리·정책·사고 대응·기록 — 을 "체계적으로 하고 있는가, 그리고 증명할 수 있는가"를 본다는 점을 이해하는 것입니다.
그래서 운영관리자에게 인증 대응은 별도의 특수 업무가 아니라, 평소의 운영을 기록과 함께 일관되게 하는 일의 연장입니다. 권한 부여에 승인 기록이 남고, 퇴사자 계정 회수가 절차로 돌고, 사고 대응이 문서로 정리되어 있으면 — 인증은 그 운영의 증거를 보여주는 일이 됩니다. 반대로 평소에 기록 없이 임기응변으로 굴리면, 인증 시즌마다 없는 증거를 만드느라 고생합니다.
정확한 인증 항목·적용 대상·심사 기준은 시기와 기관에 따라 달라지므로, 단정해서 외우기보다 소관 규정과 최신 기준 문서를 확인하는 습관이 더 안전합니다. 운영관리자가 갖춰야 할 것은 인증 지식 자체보다, "우리 운영이 보안 관점에서 일관되고 기록되어 있는가"를 스스로 점검하는 눈입니다.
관련 모듈로 더 깊이:
- 공급자·협력사 관리 — 외부 공급자·협력사의 보안과 접근 권한까지 계약·점검으로 통제하는 법
- 인시던트 관리 — 보안 사고가 터졌을 때 인시던트 절차로 탐지·대응·복구하는 흐름
- 변경 관리(변경 활성화) — 권한·설정 변경을 승인 기록과 함께 안전하게 반영하는 변경 관리
다음 모듈에서는 이 운영 책임이 외부로 확장되는 지점 — 공급자·협력사 관리, 즉 우리가 직접 통제하지 못하는 외부 인력·업체의 작업 품질과 보안을 어떻게 계약·점검·관리하는지를 다룹니다.