[ISMS-P] 멀티 클라우드 환경 중견기업의 외부자 보안 (2.3.1 ~ 2.3.4)
클라우드 전환이 가속화되면서 중견기업들은 CSP(클라우드 서비스 제공자), MSP(관리형 서비스 제공자), SaaS 벤더, 외부 개발 협력사 등 수많은 외부 이해관계자와 연결되고 있습니다. 그러나 외부자와의 협업이 늘어날수록 보안 사각지대 역시 넓어질 수밖에 없습니다.
이번 글에서는 ISMS-P 인증기준 2.3 (외부자 보안)의 4개 항목을 멀티 클라우드 환경의 중견기업 관점에서 심층적으로 살펴보고, 인증심사원 시험에 대비할 수 있는 실전 시나리오를 정리해보겠습니다.
1. 2.3.1 외부자 현황 관리
📌 인증기준 개요
업무 위탁, 시스템 유지보수, 파견 등의 형태로 정보보호 및 개인정보보호 관련 업무를 수행하는 외부자(제3자)의 현황을 파악하고, 정보보호 및 개인정보보호 요건이 반영된 계약 및 협정을 체결하여 관리해야 합니다.
☁️ 멀티 클라우드 환경에서의 핵심 고려사항
- 다층적 외부자 구조: 멀티 클라우드 환경에서는 AWS·Azure·GCP와 같은 1차 CSP뿐만 아니라, 클라우드 운영을 대행하는 MSP, 그 MSP가 다시 활용하는 서브벤더(4차 이상의 공급망)까지 외부자 범위가 매우 복잡하게 얽혀 있습니다. 이 모든 이해관계자를 목록화하고 현행화해야 합니다.
- 클라우드 공동 책임 모델(Shared Responsibility Model) 반영: 계약서 및 협정에 CSP별 공동 책임 범위를 명확히 정의하여, 보안 공백이 발생하지 않도록 해야 합니다. (예: AWS는 인프라 보안을 담당하고, 애플리케이션·데이터 보안은 고객사 책임임을 명시)
- SaaS 서비스 계약 누락 주의: 부서 차원에서 임의 도입하는 SaaS(예: 협업 툴, AI 서비스 등)는 계약 관리 대상에서 누락되기 쉬우므로, IT/보안 부서의 공식 검토·승인 절차가 필요합니다.
📝 실전 시험 대비 (기출 복원 시나리오)
[상황] 심사원이 A기업의 외부자 계약 현황을 검토 중이다.
- 심사원: “현재 귀사의 클라우드 운영을 위탁하고 있는 외부 업체 목록을 보여주실 수 있나요?”
- 담당자: “네, AWS를 대행해주는 AA MSP사와 Azure를 담당하는 BB IT서비스사 두 곳과 정식 계약을 맺고 있습니다. 관련 보안 요건도 계약서에 명시되어 있습니다.”
- 심사원: “그렇군요. 그런데 마케팅팀에서 데이터 분석을 위해 사용 중인 CC SaaS 분석 툴은 어떻게 관리되고 있나요?”
- 담당자: “CC 툴은 마케팅팀에서 팀 예산으로 직접 구독한 것으로, 저희 IT팀에서는 인지하지 못했습니다. 외부자 목록에도 포함되어 있지 않습니다.”
Q. 위 인터뷰 상황에서 식별할 수 있는 결함 항목으로 가장 적절한 것은?
- 2.3.2 외부자 계약 시 보안 - 외부자와의 계약에 보안 요건이 포함되지 않음
- 2.1.3 정보자산 관리 - 외부 SaaS를 통해 처리되는 데이터가 자산 목록에서 누락됨
- 2.3.1 외부자 현황 관리 - 업무 관련 외부자(SaaS 벤더)가 공식 현황 목록에서 누락되어 관리되지 않고 있음 (정답)
- 2.2.1 주요 직무자 지정 및 관리 - 마케팅팀의 외부 툴 접근 권한이 최소화되지 않음
해설: SaaS 형태의 외부 서비스도 업무 관련 외부자에 해당합니다. 이를 IT/보안 부서의 공식 검토 없이 임의로 사용하고, 외부자 목록에도 등록하지 않은 것은 2.3.1 외부자 현황 관리의 핵심 결함입니다. 실제 심사에서는 이처럼 공식 계약 외 비공식 경로로 사용 중인 외부 서비스(‘쉐도우 SaaS’)를 찾아내는 것이 주요 포인트입니다.
2. 2.3.2 외부자 계약 시 보안
📌 인증기준 개요
외부 서비스를 이용하거나 외부자에게 업무를 위탁하는 경우, 정보보호 및 개인정보보호 관련 의무, 책임, 보안 통제 사항, 준수 여부 확인 방법 등을 계약서에 반드시 포함하고 이를 이행해야 합니다.
☁️ 멀티 클라우드 환경에서의 핵심 고려사항
- 데이터 처리 위치(Data Residency) 명시: 클라우드 환경에서는 데이터가 어느 국가 또는 리전(Region)에 저장·처리될 수 있는지 계약서에 명확히 명시하여, 국외 이전 규정 준수 여부를 관리해야 합니다.
- 감사 권한(Audit Right) 확보: 외부자(특히 SaaS·MSP)의 보안 수준을 검증할 수 있도록 계약서에 보안 감사 요청 권한 또는 SOC2, ISO27001 등 제3자 인증 보고서 제공 의무를 명시해야 합니다.
- 보안 사고 시 통보 의무: 외부자 측에서 보안 사고가 발생하거나 고객사 데이터에 영향을 줄 수 있는 이벤트가 발생할 경우, 몇 시간 이내에 통보해야 하는지 SLA(서비스 수준 협약)에 포함시켜야 합니다.
- 계약 종료 시 데이터 파기 조항: 서비스 계약 종료 시 외부자가 보유하고 있는 개인정보·업무 데이터를 어떠한 방식으로, 언제까지 파기·반환하는지에 대한 조항이 포함되어야 합니다.
📝 실전 시험 대비 (예상 시나리오)
[상황] B기업은 고객 CRM 데이터를 글로벌 SaaS 솔루션 업체에 위탁 운영 중이다. 심사원이 해당 계약서를 검토하고 있다.
- 심사원: “CRM SaaS 계약서에 개인정보 처리 위탁에 관한 보안 의무가 명시되어 있나요?”
- 담당자: “네, 데이터 암호화 전송 및 접근 통제 조항이 있습니다.”
- 심사원: “계약 만료 시 귀사의 데이터와 개인정보는 어떻게 처리되나요?”
- 담당자: (계약서 확인 후) “계약서에 서비스 종료 후의 데이터 파기나 반환에 관한 조항이 별도로 명시되어 있지 않습니다.”
- 심사원: “만약 이 업체에서 보안 사고가 발생하면 귀사에 언제 통보하도록 되어 있나요?”
- 담당자: “통보 기한에 대한 내용도 계약서에 명시되어 있지 않습니다.”
Q. 위 상황에서 도출되는 결함으로 가장 적절한 것은?
- 2.3.1 외부자 현황 관리 - 외부 SaaS 업체가 외부자 현황 목록에 등재되어 있지 않음
- 2.4.1 보호구역 지정 - 외부 SaaS 서버의 물리적 보안이 확인되지 않음
- 2.3.2 외부자 계약 시 보안 - 계약 종료 시 데이터 파기 방법과 보안 사고 통보 기한 등의 필수 보안 요건이 계약서에 포함되어 있지 않음 (정답)
- 2.6.4 개인정보 파기 - 개인정보 파기 절차가 수립되지 않음
해설: 외부 위탁 계약서에는 데이터 암호화·접근 통제 외에도 ① 계약 종료 후 데이터 파기/반환, ② 보안 사고 발생 시 통보 의무(기한 포함), ③ 감사 권한 등이 반드시 포함되어야 합니다. 이러한 항목이 누락된 것은 2.3.2의 명확한 결함입니다.
3. 2.3.3 외부자 보안 이행 관리
📌 인증기준 개요
외부자가 계약서 및 협정에 정의된 보안 요건을 실제로 준수하고 있는지 정기적으로 검토·점검하고, 미흡한 사항이 발견될 경우 개선 조치를 요구해야 합니다.
☁️ 멀티 클라우드 환경에서의 핵심 고려사항
- CSP 보안 컴플라이언스 검증: AWS Artifact, Azure Trust Center, GCP Compliance Reports 등을 통해 CSP가 주요 보안 인증(ISO 27001, SOC2 등)을 유지하고 있는지 주기적으로 확인해야 합니다.
- MSP 현장 점검 또는 원격 모니터링: MSP가 실제로 계약상 보안 절차(접근 로그 관리, 취약점 점검, 패치 관리 등)를 이행하고 있는지 정기 점검(연 1회 이상) 또는 원격 모니터링(대시보드 등)을 통해 검증해야 합니다.
- 제3자 인증 보고서 활용: 대형 SaaS 업체의 경우 직접 현장 점검이 어려울 수 있으므로, SOC2 Type II 보고서, ISO 27001 인증서 등의 제3자 인증 결과를 검토하는 것이 실질적인 대안이 될 수 있습니다.
📝 실전 시험 대비 (기출 복원 유형)
Q. 다음 중 2.3.3 외부자 보안 이행 관리 결함으로 가장 적절한 것은?
- 외부 협력업체 직원의 입·퇴사 시 보안 서약서를 징구하지 않았다.
- 외부 MSP와의 계약서에 데이터 암호화 요건이 포함되어 있지 않다.
- 외부 MSP와 보안 요건이 포함된 계약을 체결하였으나, 계약 체결 이후 해당 MSP가 보안 요건을 실제로 이행하고 있는지 점검한 이력이 전혀 없다. (정답)
- 외부 클라우드 서버실에 대한 물리적 출입 통제 현황을 파악하지 못하고 있다.
해설: 계약서 체결(2.3.2)과 이행 점검(2.3.3)은 별개의 인증 항목입니다. 계약서에 보안 요건을 잘 명시해 두었더라도 실제 이행 여부를 정기적으로 검토·확인하지 않는 것은 2.3.3의 결함에 해당합니다. 계약 체결과 이행 점검을 혼동하지 않도록 주의가 필요합니다.
4. 2.3.4 외부자 계약 변경 및 만료 시 보안
📌 인증기준 개요
외부자와의 계약이 변경·갱신·만료·종료될 경우, 제공하였던 정보자산·접근 권한·출입 자격 등을 적시에 회수하고, 업무 과정에서 취득한 정보의 비밀 유지 의무가 계속해서 유지될 수 있도록 관리해야 합니다.
☁️ 멀티 클라우드 환경에서의 핵심 고려사항
- 클라우드 IAM 계정 즉시 회수: 계약 만료 또는 외부 인력 교체 시, 해당 인원에게 발급된 AWS IAM 사용자, Azure AD 게스트 계정, GCP 서비스 계정 등을 즉시 비활성화 또는 삭제해야 합니다. 클라우드 계정은 온프레미스 계정보다 간과되기 쉬우므로 특별히 주의해야 합니다.
- API 키 및 서비스 자격 증명 폐기: 외부 개발사나 MSP에게 발급된 API 키, 액세스 토큰, SSH 키 등 클라우드 자격 증명도 계약 종료 즉시 폐기하고, 이를 사용하던 자동화 스크립트나 시스템에서 교체하는 프로세스가 마련되어야 합니다.
- 데이터 반환 및 파기 확인: 외부자가 업무 과정에서 수집·보유한 개인정보나 내부 데이터에 대해 계약서에 명시된 절차대로 파기 또는 반환이 이루어졌는지 확인하고, 파기 증적(파기 확인서 등)을 수령해야 합니다.
📝 실전 시험 대비 (예상 시나리오)
[상황] C기업은 1년간 클라우드 운영을 맡겼던 DD MSP사와의 계약을 종료하였다. 심사원이 계약 종료 후 조치 현황을 확인 중이다.
- 심사원: “DD MSP와의 계약이 한 달 전에 종료되었는데, 이후 조치 사항을 확인해볼게요. 먼저 DD MSP 담당자에게 발급했던 클라우드 계정은 어떻게 처리했나요?”
- 담당자: “Azure 콘솔 계정은 계약 종료 당일 바로 비활성화했습니다.”
- 심사원: “혹시 CI/CD 파이프라인 연동을 위해 발급했던 AWS 서비스 계정 액세스 키는요?”
- 담당자: “아, 그 부분은 개발팀에서 관리하던 부분인데… 확인해보니 아직 키가 삭제되지 않은 상태로 남아 있었습니다.”
- 심사원: “그리고 DD MSP가 운영 과정에서 보유했던 고객 데이터 백업본에 대한 파기 확인서는 수령하셨나요?”
- 담당자: “파기 확인서는 아직 요청하지 않았습니다.”
Q. 위 상황에서 2.3.4 외부자 계약 변경 및 만료 시 보안의 결함으로 식별되는 것을 모두 고르시오.
- ① Azure 콘솔 계정 비활성화 처리
- ② AWS 서비스 계정 액세스 키 미삭제
- ③ 고객 데이터 파기 확인서 미수령
- ④ 계약 종료 사실을 전 직원에게 공지하지 않음
- 정답: ②, ③
해설:
- ①: 계약 종료 당일 즉시 비활성화한 것은 적절한 조치로 결함이 아닙니다.
- ②: 클라우드 IAM 계정(콘솔)만 처리하고 API 키 등 자격 증명을 누락한 것은 명백한 2.3.4 결함입니다. 특히 CI/CD 등 자동화에 사용된 자격 증명은 간과되기 쉬운 고위험 항목입니다.
- ③: 계약 종료 후 외부자가 보유한 데이터의 파기 확인서를 수령하지 않은 것 역시 2.3.4의 결함입니다.
- ④: 계약 종료 사실을 전 직원에게 공지하는 것이 의무 사항은 아니므로 결함이 아닙니다.
🚀 AI를 활용한 외부자 보안 자동화 의견
멀티 클라우드 환경에서는 수십~수백 곳의 외부 벤더, 개발사, SaaS 공급자와 복잡한 관계를 형성합니다. 수동으로 이를 관리하는 것은 현실적으로 어려우며, AI와 자동화 기술의 도입이 필수적입니다.
1. AI 기반 제3자 위험 관리 (Third-Party Risk Management, TPRM 자동화)
- 외부자 자동 등록 및 분류: AI가 계약·발주 시스템과 연동하여 새로운 외부자 계약을 감지하면 자동으로 외부자 목록에 등재하고, 보안 민감도(취급 데이터 등급, 시스템 접근 범위)를 기반으로 외부자의 보안 위험 등급을 자동 분류합니다. (2.3.1 대응)
- 계약서 AI 검토: LLM 기반 계약서 분석 기능을 활용하여 신규 계약서에 보안 필수 항목(데이터 파기 조항, 사고 통보 기한, 감사 권한 등)이 누락되었을 때 자동으로 경고를 발생시키고 보완 문구를 추천합니다. (2.3.2 대응)
2. 지속적인 외부자 보안 모니터링 (Continuous Vendor Security Monitoring)
- 실시간 취약점 감시: AI 기반 공급망 보안 플랫폼이 외부자의 IP 대역, 공개 도메인, 다크웹 유출 데이터를 실시간으로 모니터링하여 계약된 외부자의 보안 수준 저하를 조기에 탐지합니다.
- 보안 인증 자동 갱신 추적: 외부자의 ISO 27001, SOC2 등 인증 만료일을 자동으로 추적하여 갱신이 안 된 경우 알림을 발송하고, 갱신된 인증 보고서의 수령을 자동으로 요청합니다. (2.3.3 대응)
3. 자동화된 오프보딩 워크플로우 (Automated Vendor Offboarding)
- 계약 종료 자동 감지 및 알림: 계약 관리 시스템과 연동하여 계약 만료 N일 전 보안 담당자에게 오프보딩 절차 시작을 자동 알림합니다.
- 멀티 클라우드 자격 증명 통합 회수: 계약 종료 시 IAM 계정, API 키, SSH 키, 서비스 계정 등 클라우드 전반의 자격 증명을 단일 워크플로우에서 일괄 회수하고, 회수 완료 여부를 자동으로 보고합니다. 인력에 의존하는 수동 오프보딩 과정에서 발생하는 누락을 원천 차단합니다. (2.3.4 대응)
💡 요약 및 결론
멀티 클라우드 환경에서 외부자 보안(2.3)은 공급망 전체에 걸친 보안 리스크를 관리하는 핵심 영역입니다. 4개 항목을 한 문장으로 정리하면 다음과 같습니다.
| 항목 | 핵심 키워드 | 클라우드 핵심 주의사항 |
|---|---|---|
| 2.3.1 외부자 현황 관리 | 누락 없는 목록 현행화 | 쉐도우 SaaS, 서브벤더 포함 등재 |
| 2.3.2 외부자 계약 시 보안 | 필수 보안 요건 계약 반영 | 데이터 파기 조항, 사고 통보 기한, 감사 권한 |
| 2.3.3 외부자 보안 이행 관리 | 계약 후 정기 이행 점검 | SOC2/ISO27001 보고서 검토, MSP 정기 점검 |
| 2.3.4 계약 변경·만료 시 보안 | 자격 회수 및 데이터 파기 확인 | API 키·클라우드 계정 포함 전체 자격 회수 |
ISMS-P 인증심사원 시험에서는 계약 체결(2.3.2)과 이행 점검(2.3.3)의 혼동, 그리고 계약 종료 시 API 키 등 클라우드 자격 증명 미회수(2.3.4) 시나리오가 자주 출제되므로, 각 항목의 경계를 명확히 이해하는 것이 합격의 핵심입니다.
외부자 보안은 ‘우리 회사 안’에서 끝나지 않습니다. 우리와 연결된 모든 파트너와 공급망이 보안 수준을 함께 유지할 때 비로소 진정한 ISMS-P 관리체계가 완성됩니다.