퍼블릭 서비스 선택 시 가장 먼저 확인할 보안 체크리스트

By PLURA

퍼블릭 서비스 도입은 이제 특별한 일이 아닙니다.
협업툴, 화상회의, 전자결재, CRM, 파일공유, 개발도구까지 많은 업무가 이미 퍼블릭 SaaS 위에서 돌아갑니다.

문제는 도입 속도보다 보안 점검 속도가 더 느리다는 점입니다.

서비스는 편리하지만,
잘못 고르면 다음과 같은 문제가 한 번에 생길 수 있습니다.

  • 계정 탈취로 인한 대량 정보 유출
  • 외부 협업 링크를 통한 문서 노출
  • 관리자 계정 오남용
  • 보안 로그 부족으로 사고 원인 추적 실패
  • 데이터가 어디에 저장되고 누구에게 이전되는지 불명확
  • 공급망 사고 발생 시 고객사가 통제할 수 있는 범위 부족

그래서 퍼블릭 서비스를 고를 때 가장 먼저 봐야 할 것은 기능이 아니라 보안 기본값입니다.

untact_ontact

왜 지금은 “기능”보다 “보안 기본값”을 먼저 봐야 하는가

예전에는 퍼블릭 서비스 보안을
“비밀번호 잘 관리하면 되는 문제” 정도로 보는 경우가 많았습니다.

하지만 지금은 다릅니다.

NIST가 설명하듯, 보안은 더 이상 넓은 네트워크 경계 하나를 믿는 방식이 아니라
사용자, 자산, 리소스 중심으로 계속 검증하는 제로 트러스트 방식으로 이동하고 있습니다.
또 CISA는 클라우드·SaaS 서비스에서 MFA, SSO, 보안 로그 제공을 기본 제공 기능으로 강조합니다.

즉, 퍼블릭 서비스를 고를 때는
“이 서비스가 유명한가?”보다
“기본 상태에서 얼마나 안전한가?”를 먼저 물어야 합니다.

최소한 이것부터: 인증과 접근통제

기존 ISMS-P의 사용자 인증 관점은 여전히 중요합니다.
다만 2026년에는 아래 수준까지 봐야 실무적으로 의미가 있습니다.

반드시 확인할 항목

  1. MFA 기본 지원 여부

    • 관리자 계정만이 아니라 일반 사용자까지 적용 가능한가
    • SMS만이 아니라 OTP, FIDO2, 앱 기반 인증을 지원하는가

  2. SSO / IdP 연동 여부

    • Microsoft Entra ID, Google Workspace, Okta 등과 연동되는가
    • 퇴사자 계정 비활성화가 자동으로 반영되는가

  3. 접속 세션 통제

    • 유휴 세션 자동 만료
    • 장기 로그인 제한
    • 새로운 디바이스 로그인 시 추가 인증

  4. 로그인 실패·이상 로그인 방어

    • 실패 횟수 제한
    • 비정상 국가/ASN/디바이스 탐지
    • 크리덴셜 스터핑 방어 기능

  5. 관리자 계정 분리

    • 일반 사용자 계정과 관리자 계정 분리
    • 관리자 작업에 대한 추가 인증 적용
    • 특권 기능 실행 시 별도 검증 가능 여부

단순히 “2차 인증이 있다” 정도로 끝내면 부족합니다.
관리자 계정 보호, SSO 연동, 비정상 로그인 탐지까지 확인해야 합니다.

실제 도입 전에 꼭 보는 10가지 보안 체크리스트

항목 반드시 확인할 질문 왜 중요한가
1. MFA 모든 관리자와 사용자에게 MFA를 강제할 수 있는가 계정 탈취 방어의 기본
2. SSO 사내 IdP와 연동되는가 계정 수명주기와 권한 회수 자동화
3. 로그 제공 로그인, 관리자 행위, 파일 접근, 공유 변경, API 호출 로그를 제공하는가 사고 추적과 포렌식의 핵심
4. 로그 보존 로그를 얼마나 오래 보관하며 외부 SIEM/XDR로 내보낼 수 있는가 사후 분석과 규제 대응
5. 데이터 위치 데이터 저장 지역과 백업 지역을 확인할 수 있는가 데이터 주권과 규제 대응
6. 암호화 저장 시 암호화와 전송 시 암호화를 기본 제공하는가 기본 보호 수준 확인
7. 관리자 통제 역할 기반 권한 관리(RBAC)와 세분화된 관리자 권한이 가능한가 내부 오남용 방지
8. 외부 공유 통제 링크 공유 만료, 비밀번호, 도메인 제한, 다운로드 금지 등이 가능한가 협업 중 유출 방지
9. 공급망 보안 사고 발생 시 고객 통지, 취약점 대응, 서드파티 의존성 공개 수준이 적절한가 SaaS 리스크 관리
10. 감사·인증 SOC 2, ISO 27001, CSA CCM/STAR 등 외부 검증 자료를 확인할 수 있는가 최소 신뢰 근거 확보

CSA의 Cloud Controls Matrix는 클라우드 보안 평가에 사용할 수 있는 대표 프레임워크이며, 최신 Security Guidance v5는 IAM, 데이터 보안, 로깅, 공급망, 제로 트러스트를 핵심 영역으로 다룹니다.

“있으면 좋다”가 아니라 “없으면 위험하다”인 항목들

1. 보안 로그 외부 연동

많은 SaaS가 관리 콘솔 화면에서는 이벤트를 보여주지만,
실제 보안 운영에 필요한 수준으로 외부 전송이 안 되는 경우가 있습니다.

확인해야 할 질문은 간단합니다.

  • 로그인 로그를 API나 SIEM으로 보낼 수 있는가
  • 관리자 설정 변경 로그가 남는가
  • 파일 공유, 다운로드, 외부 링크 생성 로그가 남는가
  • API 토큰 생성·사용 이력이 남는가

CISA는 클라우드 서비스가 보안 관련 로그를 추가 비용 없이 생성·저장·제공해야 한다고 강조합니다.

2. 데이터 주권과 이전 통제

소버린 AI나 소버린 사이버보안 관점에서 보면,
퍼블릭 서비스 선택 시 데이터가 어디에 저장되고 어디로 이동하는가는 점점 더 중요해지고 있습니다.

특히 아래는 꼭 확인해야 합니다.

  • 데이터 저장 국가
  • 백업 저장 위치
  • 고객 데이터의 AI 학습 활용 여부
  • 하위 처리자(subprocessor) 목록 공개 여부
  • 데이터 삭제 요청 시 실제 삭제 절차

기능이 아무리 좋아도,
이 질문에 답하지 못하는 서비스는 민감 업무에 바로 쓰기 어렵습니다.

3. 외부 공유와 링크 기반 유출 방지

실제 사고는 해킹보다
공유 링크 하나 잘못 열어 놓아서 생기는 경우도 많습니다.

그래서 다음이 중요합니다.

  • 링크 만료 설정
  • 조직 외부 공유 제한
  • 특정 도메인만 공유 허용
  • 다운로드 차단
  • 워터마크
  • 비인가 기기 차단

2026년 기준으로 더 중요해진 항목

Zero Trust 적용 가능성

퍼블릭 서비스는 내부망 밖에 있기 때문에,
오히려 더 제로 트러스트 관점으로 봐야 합니다.

즉, 다음이 가능해야 합니다.

  • 사용자만이 아니라 디바이스 상태까지 조건부 접근
  • 위치 기반이 아니라 리스크 기반 접근
  • 최소 권한
  • 세션별 지속 검증

NIST는 제로 트러스트를 사용자, 자산, 리소스 중심의 접근제어 패러다임으로 설명합니다. 퍼블릭 서비스 평가에서도 이 기준이 중요합니다.

AI 기능의 기본 보안

요즘 많은 SaaS가 요약, 검색, 자동작성, 코파일럿 기능을 붙입니다.
그래서 이제는 이런 질문도 필요합니다.

  • 입력한 데이터가 모델 재학습에 쓰이는가
  • 조직 데이터를 다른 고객과 섞어 쓰지 않는가
  • AI 기능을 끌 수 있는가
  • AI 관련 접근 로그가 남는가

즉, 이제는 협업툴도 “기능 보안”이 아니라 AI 보안까지 봐야 합니다.

공급망과 사고 공지

퍼블릭 서비스는 결국 공급망입니다.
고객사는 직접 코드를 보지 못하므로, 사고가 나면 얼마나 빨리, 얼마나 투명하게 알려주는가가 중요합니다.

반드시 확인해야 합니다.

  • 보안 사고 통지 SLA
  • 취약점 공개 정책
  • 고객 영향 범위 안내 수준
  • 하위 서비스 장애 시 공지 체계

도입 전에 보안팀이 실제로 물어야 할 질문

아래 질문에 명확히 답하지 못하면, 도입은 늦추는 편이 낫습니다.

  1. 관리자 계정 MFA를 강제할 수 있습니까?
  2. 우리 회사 SSO와 연동됩니까?
  3. 보안 로그를 외부 SIEM/XDR로 보낼 수 있습니까?
  4. 데이터는 어느 국가에 저장됩니까? 백업 위치도 같습니까?
  5. 외부 공유 링크를 만료·비밀번호·도메인 제한으로 통제할 수 있습니까?
  6. 관리자 행위와 설정 변경 이력이 모두 남습니까?
  7. AI 기능이 있다면 우리 데이터가 모델 학습에 사용됩니까?
  8. 보안 사고가 발생하면 고객에게 언제, 어떤 수준으로 알려줍니까?
  9. 하위 처리자와 외부 의존 서비스 목록을 공개합니까?
  10. 감사 보고서나 독립 검증 자료를 제공할 수 있습니까?

이 질문은 단순한 체크리스트가 아닙니다.
실제로 사고가 났을 때 우리가 무엇을 볼 수 있고, 무엇을 통제할 수 있는가를 묻는 질문입니다.

ISMS-P 관점에서 다시 보면

기존 글에서 강조했던 사용자 인증 항목은 여전히 유효합니다.
다만 지금은 그것만으로 부족합니다.

ISMS-P의 인증 및 권한관리 관점을 실무적으로 확장하면 다음처럼 볼 수 있습니다.

  • 접속 세션 만료
  • 인증 실패 횟수 제한
  • 접속 가능한 IP 또는 조건부 접근 제한
  • MFA
  • 관리자 계정 분리
  • 로그와 감사 가능성
  • 권한 변경 추적
  • 외부 공유 통제
  • 데이터 이전 통제

즉, 인증은 출발점일 뿐이고,
지금은 접근통제 + 로그 + 데이터 통제 + 공급망 관리까지 함께 봐야 합니다.

PLURA 관점에서 보면 왜 중요한가

Plura 블로그에서 이 주제를 다시 쓰는 이유는 분명합니다.

퍼블릭 서비스를 잘 고른다는 것은
단지 “좋은 SaaS를 선택한다”는 뜻이 아닙니다.
그 서비스가 만들어내는 로그, 인증 이벤트, 관리자 행위, 외부 공유 이력을
우리 보안 체계 안에서 계속 볼 수 있어야 한다는 뜻입니다.

아무리 좋은 퍼블릭 서비스라도,

  • 로그인 기록을 제대로 못 받고
  • 관리자 행위가 남지 않고
  • 외부 공유 이력을 추적하지 못하고
  • 사고 시 타임라인을 복원할 수 없다면

실제 보안 운영에서는 큰 약점이 됩니다.

그래서 퍼블릭 서비스 선택은 구매팀의 기능 검토가 아니라,
보안 운영 가능성을 먼저 따지는 일이어야 합니다.

결론

퍼블릭 서비스 선택에서 가장 중요한 질문은
“이 서비스가 편리한가?”가 아닙니다.

“문제가 생겼을 때 우리가 통제할 수 있는가?”
이 질문이 먼저입니다.

2026년 기준으로 최소한 확인해야 할 기준은 분명합니다.

  • MFA와 SSO
  • 세션 및 관리자 통제
  • 보안 로그 제공
  • 데이터 저장 위치와 이전 통제
  • 외부 공유 제한
  • 공급망 투명성
  • 제로 트러스트 적용 가능성
  • AI 기능의 데이터 처리 원칙

이 기준을 통과하지 못하는 퍼블릭 서비스는
아무리 기능이 좋아도 중요한 업무에 바로 쓰기 어렵습니다.

퍼블릭 서비스를 고를 때 가장 먼저 봐야 할 것은 기능이 아니라 보안 기본값입니다.
그리고 그 보안은 인증 한 줄이 아니라, 로그·데이터·관리자 통제까지 포함해야 합니다.

📖 함께 보면 좋은 기준

  • NIST Zero Trust Architecture (SP 800-207)
  • CISA Secure by Design / Secure by Demand 가이드
  • CSA Security Guidance v5 / Cloud Controls Matrix

Tags