REPORT
2025-12-31
테스트중입니다. SaaS 보안 아키텍처 설계 : 규제 대응 테스트중입니다. SaaS 보안 아키텍처 설계 : 규제 대응테스트중입니다. SaaS 보안 아키텍처 설계 : 규제 대응테스트…
오픈인프라 한국 커뮤니티 / 김관영 부회장
그로메트릭 / 김관영 대표
1. SaaS 보안 아키텍쳐 설계 : 글로벌 규제 환경에 대응하는 기술적 기준
1-1. 규제가 소프트웨어 구조를 결정하는 시대
기업의 중요 업무 시스템인 그룹웨어, ERP, CRM, HR 등을 비롯해 공공, 금융, 의료 등 높은 안정성이 요구되는 분야에서도 SaaS 기반의 전환이 단계적, 지속적으로 이루어지고 있다. 이는 운영 및 접근 효율성과 비용 최적화라는 실질적인 이점에 기인하나, 이러한 변화는 필연적으로 보안과 서비스 안정성에 대한 더 높은 수준의 검증을 요구하고 있다.
이제 SaaS 기업에게 컴플라이언스 준수와 데이터 보호 책임은 단순한 기능적 요구사항이 아니다. 따라서 서비스 제공자에게 부여되는 컴플라이언스 준수와 데이터 보호의 책임은 단순한 요구사항을 넘어, 비즈니스의 지속 가능성을 결정짓는 중요한 전제 조건이 되었다.
SaaS는 ‘데이터가 사용자 조직 내부를 떠나 외부 클라우드 사업자 환경에서 처리된다’는 구조적 특성 때문에, 국내외 규제 기관은 SaaS의 보안 기능을 세부적으로 요구하고 있다. 한국에서는 개인정보보호법, ISMS-P, CSAP(공공), 전자금융감독규정(금융) 등이 기준을 제시하고 있으며, 해외에서는 GDPR(EU), NIS2(EU), DORA(EU 금융), SOC 2(미국), CCPA/CPRA(캘리포니아), HIPAA(의료) 등 다양한 규제가 SaaS의 구조적 설계와 운영 방식에 직접적인 영향을 주고 있다.
이러한 규제 환경을 종합적으로 분석하고, SaaS 제공자(B2B 서비스 사업자)가 어떤 요소를 고려해야 국내외 규제를 동시에 충족할 수 있는지를 기술적·구조적 관점에서 설명하고자 한다.
2. 규제 환경 분석: 국가별 산업별 요구사항에 대한 공통점과 차이점
2-1. 한국 규제: 데이터 보호와 운영 책임 강화
한국의 SaaS 규제 체계는 데이터 보호와 운영 책임의 명확성을 중심으로 SaaS의 기술 구조를 규정하고 있다. 개인정보보호법, 정보통신망법 기반의 ISMS-P 인증, 공공용 CSAP, 금융 부문의 전자금융감독규정 등이 이에 해당된다.
개인정보보호법은 개인정보(가명정보도 포함하여)의 수집·이용·보유·파기 전 과정에 대해 관리 기준을 제시한다. SaaS는 고객을 대신해 데이터를 보관하고 처리하는 개인정보 처리업무 위탁에 해당되기 때문에, 데이터 보유 기간 준수·각 단계별 로그 기록·파기 자동화가 의무화된다. 업무위탁의 목적 및 범위, 재위탁 제한, 안전조치 의무(기술적 관리적), 수탁자에 대한 관리/감독이 이에 포함된다.
ISMS-P는 정보보호 및 개인정보보호를 위한 일련의 조치와 활동이 인증기준에 적합함을 인증심사를 수행하는 심사기관과 이를 최종 인증하는 인터넷진흥원과 금융보안원에서 증명하는 제도이다. SaaS 서비스에 법적으로 법적으로 강제되는 의무 사항은 아니지만 보안 신뢰성을 판단하는 기준이 되고 있다고 볼 수 있다. 정보보호 관리체계와 개인정보 보호조치를 아우르는 방대한 심사 기준(100여 개 항목)을 적용하며, 그 중에서도 데이터 위변조 방지와 강력한 접근통제 체계가 무엇보다 강조된다.
공공기관 대상 SaaS는 CSAP(Cloud Security Assurance Program) 인증이 필수다. CSAP은 관리망과 서비스망 분리, 운영자 접근통제, 데이터 암호화, DR(재해복구) 구조 등 공공 환경에서 요구하는 기준을 기술적으로 구현하도록 요구한다.
금융기관 대상 SaaS는 전자금융감독규정의 적용을 받는다. 금융사는 클라우드를 사용할 때 SaaS의 안정성·가용성·보안·로그 투명성 등을 직접 평가해야 하며, 중요 업무로 지정될 경우 더 높은 수준의 통제가 요구된다. 금융보안원에서 발간한 금융분야 클라우드컴퓨팅 서비스 이용 가이드(2025 개정)에 따르면 SaaS 이용을 위해서는 이용 업무의 중요도 평가와 클라우드 서비스 제공자에 대한 안전성, 건전성 평가를 선행하고, 그 결과에 따라 업무 연속성 계획, 보안조치 수립, 정보보호위원회 심의, 계약 및 이용 보고 절차를 이행해야 한다.
2024년 9월 금융위원회는 14건의 혁신금융서비스에 대해 ‘클라우드 기반 SaaS의 내부망 이용’을 승인했다. 이 변화는 그간 금융권 SaaS 도입을 가로막았던 망분리 규제를 사실상 완화한 첫 사례라는 점에서 의미가 크다. 다만 허용은 무제한이 아니다. 금융거래정보와 같이 민감한 데이터는 여전히 대상에서 제외되며, 지정 기업은 보안성 평가를 통과한 CSP를 이용한 SaaS만 사용할 수 있고, 망분리 예외로 생길 수 있는 보안 위협에 대해 별도 대책을 세워야 한다.
따라서 금융권을 겨냥한 SaaS 설계에는 “외부망 연결 시점의 보안 통제 - 암호화, 접근관리, 로그/모니터링 강화, 운영자 권한 분리, 데이터 격리 및 암호화, 데이터 범위 제한” 등의 요소가 필수적이다. 제로 트러스트 - 데이터 보호 - 감사 투명성 아키텍처 모델이 단지 이상적인 관점만이 아니라, 실질적인 시장 요구 조건이 되었음을 의미한다.
2-2. EU 규제: 프라이버시·공급망·운영 탄력성 중심
EU는 글로벌 규제 중 가장 높은 수준의 프라이버시와 공급망 보안 기준을 요구한다.
GDPR(General Data Protection Regulation)은 삭제권, 가명처리, 데이터 최소 수집 원칙을 명확하게 요구한다. EU 시민의 개인정보는 EU 지역 내 저장을 원칙으로 하며(EU 데이터 주권), 타 지역으로 이전할 경우 ‘표준계약조항(SCCs)’을 체결해야 한다. GDPR은 SaaS 설계 단계에서 “삭제 가능한 스키마 구조”와 “가명처리(pseudonymization)”를 필수적으로 고려하게 만든다.
NIS2(Network and Information Security Directive 2)는 EU 전체의 사이버보안 최상위 법령으로, 공급망 보안 요구가 매우 강화됐다. SaaS는 오픈소스·외부 라이브러리 등 소프트웨어 구성 요소를 투명하게 관리해야 하며, 사고 발생 시 24시간 이내에 초기 보고를 해야 한다.
DORA(Digital Operational Resilience Act)는 규제보다는 운영의 연속성에 초점이 맞춰져 있으며 금융기관이 의존하는 ICT 서비스의 운영 탄력성을 법제화한 규정이다. 금융기관과 SaaS 제공자 모두 DR 구조, 로그 보존, 모니터링, 침해 대응 체계를 갖춰야 하며, 중요한 SaaS 제공자는 EU 공동 감독 기구의 감독 대상이 될 수 있다.
2-3. 미국 규제: 서비스 신뢰성과 소비자 프라이버시 중심
미국에서는 GDPR과 같은 단일 연방 개인정보법보다는 주(State) 단위의 프라이버시 규제가 중심을 이룬다. 대표적으로 CCPA/CPRA(캘리포니아 프라이버시 법)는 소비자에게 개인정보 열람·삭제·처리 거부 권리를 보장하며, SaaS 사업자가 고객 데이터를 제3자에게 판매 또는 공유하는 경우 명확한 고지와 선택권을 요구한다. VCDPA (Virginia Consumer Data Protection Act), CPA (Colorado Privacy Act)도 EU의 GDPR과 CCPA와 유사한 형태로 반영되어 있다.
SOC 2(Service Organization Controls)는 법적 규제는 아니지만, SaaS의 서비스 신뢰성과 내부 통제 수준을 검증하기 위한 사실상 글로벌 표준으로 자리 잡았다. 보안, 가용성, 기밀성, 처리 무결성, 프라이버시의 다섯 가지 신뢰 원칙을 기준으로 하며, 기술 구조보다는 접근통제, 변경관리, 로그, 운영 절차 등 프로세스 중심의 통제를 중점적으로 평가한다.
한편 HIPAA(의료정보보호법)는 의료기관이나 보험사 등 의료 분야 고객을 위해 PHI(Protected Health Information)를 처리하는 SaaS에 적용되며, 이러한 경우 SaaS는 ‘Business Associate’로서 강화된 접근통제, 암호화, 감사 로그, 계약적 책임을 부담하게 된다.
3. 사용자 식별 및 접근 제어
접근통제는 글로벌 모든 규제에서 가장 일관되게 등장하는 항목이다. 사용자가 누구인지, 어떤 권한을 가지는지, 어떤 방법으로 인증하는지가 서비스 보안을 결정한다.
3-1. 중앙 집중형 인증 시스템의 필요
기업 환경에서 점차 널리 사용되는 것이 SSO(Single Sign-On)이다. SSO는 사용자가 기업의 인증 시스템(예: Okta, MS Entra ID)에 한 번 로그인하면 SaaS에도 동일한 계정으로 자동 로그인할 수 있도록 해준다. 이를 가능하게 하는 기술이 SAML(Security Assertion Markup Language) 또는 OIDC(OpenID Connect)이다.
SSO는 편의 기능처럼 보이지만, 실제로는 계정 관리의 복잡성과 보안 리스크를 줄이는 중요한 방안이다. 규제 기관은 ‘중앙에서 인증 정보를 관리하고, 모든 서비스가 동일한 계정 정책을 따르는 구조’를 선호한다.
3-2. 다단계 인증(MFA)의 기본 의무화
MFA는 비밀번호 외에 추가 인증 요소(모바일 OTP, 하드웨어 키 등)를 요구해 계정 탈취 위험을 크게 줄인다. 대부분의 규제는 관리 계정뿐 아니라 일반 사용자에게도 MFA를 권고하거나 의무화하고 있으며, 특히 공공·금융 분야는 MFA 미적용 시 인증 자체가 불가능하도록 설계해야 한다.
3-3. 운영자를 위한 임시 권한 부여(JIT)
운영자/개발자는 SaaS에서 높은 실행권한을 가지므로 보안 사고의 주요 원인이 될 수 있다. 이를 방지하기 위해 최근에는 JIT(Just-in-Time) 권한 부여가 활용된다. 이 방식은 요청(Request) → 승인(Approval) → 활성화(Elevation) → 만료(Revocation)의 단계로 진행된다. 필요할 때만 제한된 시간 동안 권한을 부여하므로, 계정이 탈취되더라도 평소에는 권한이 없는(Empty State) 상태로 유지된다. 또한 모든 요청과 승인 기록이 남고 상시 관리자 계정을 제거하여 보안 위험을 획기적으로 줄일 수 있다.
4. 데이터 보호: 규제가 가장 상세하게 요구하는 영역
데이터는 SaaS의 핵심이며, 규제는 데이터를 어떻게 저장하고 가공하고 삭제하는지 매우 구체적으로 요구한다.
4-1. 테넌트 격리의 중요성
여러 고객이 한 서비스를 공유하는 SaaS는 고객 간 데이터가 섞이면 안 된다. 이를 멀티테넌시 (Multi-Tenancy)라고 부르며, 테넌트를 격리하는 방식은 크게 두 가지다.
Silo 모델: 고객별로 별도의 DB 또는 네트워크 영역을 할당한다. 보안성이 높아 금융·공공 환경에서 선호되며 보안과 성능 측면에서 장점이 크며 리소스 활용도와 관리 측면에서의 단점이 존재한다고 볼 수 있다.
Pool 모델 + RLS(Row Level Security): 하나의 DB에서 고객별 데이터를 논리적으로 분리한다. RLS는 DB 내부에서 “특정 사용자에게 허용된 행(Row)만 조회하도록 강제하는 기능”이다. 데이터와 성능이 다른 고객에게 영향을 주지 않는 것이 핵심사항이라고 볼 수 있다.
4-2. 암호화와 키 관리
저장된 데이터는 AES-256으로 암호화하는 것이 사실상의 표준이며, 전송 구간은 TLS 1.2 또는 1.3을 사용한다. 또한 봉투 암호화(Envelope Encryption)를 적용해 데이터키(DEK)와 이를 감싸는 마스터키(KEK)를 분리 관리하는 방식으로 암호화 속도와 멀티테넌시 데이터 격리에 효과적인 적용이 가능하다.
최근에는 고객이 자신의 암호화 키를 직접 관리하는 BYOK(Bring Your Own Key) 모델이 확산되고 있다. 이는 GDPR에서 강조하는 “데이터 통제권”을 기술적으로 보장하는 방식이다.
4-3. 삭제 가능 구조와 가명처리(pseudonymization)
GDPR은 ‘잊혀질 권리’를 명시하고 있다. SaaS는 삭제 요청을 받으면 DB 구조가 이를 실제로 수행할 수 있어야 한다. 또한 개인정보를 식별정보와 분리해 저장하는 가명처리 구조는 EU·한국 모두에서 강하게 권장된다. 국내의 경우 개인정보 보호법의 개인정보의 파기 및 가명정보의 정의 및 안전조치 의무에 기반을 두고 있다.
5. 네트워크·인프라 구조: 제로 트러스트를 중심으로
5-1. 내부망도 신뢰하지 않는 제로 트러스트
제로 트러스트는 “기본적으로 아무것도 신뢰하지 않고, 항상 검증한다(Never Trust, Always Verify)”는 원칙에 기반한다. 이를 기술적으로 구현하기 위해 내부 시스템 접근 시 사용자의 신원과 맥락을 정밀하게 검증하는 IAP(Identity-Aware Proxy)와 서비스 간 통신을 암호화하고 상호 인증하는 mTLS(mutual TLS)가 필수 요소로 자리 잡았다.
이러한 체계는 경계 보안이 뚫리더라도 공격자의 내부 수평 이동(Lateral Movement)을 원천 차단하여 피해 확산을 막고, 모든 접근 행위에 대한 투명한 가시성을 확보하여 데이터 유출 사고를 선제적으로 방어하는 강력한 보안 효과를 제공한다.
아래 그림은 데이터 플레인과 콘트롤 플레인을 나뉘어져, 모든 실행은 데이터 플레인의 PEP에서, 판단은 컨트롤 플레인의 PE/PA에서 수행되며, 다양한 외부환경(규제, 인텔리전스, 정책, ID, SIEM, Log 등)과 상호작용하는 것을 나타낸다.
[그림 1. Core Zero Trust Logical Components NIST Zero Trust Architecture Reference Model (NIST SP 800-207)]
5-2. 서비스 메시(Service Mesh)의 활용
마이크로서비스 구조에서는 수많은 서비스 간 통신(East-West Traffic)이 발생하여 코드 레벨에서의 일관된 보안 관리가 매우 복잡하다. 서비스 메시는 비즈니스 로직과 네트워크 제어를 분리하여, 사이드카(Sidecar) 프록시를 통해 암호화(mTLS), 라우팅, 관찰성(Observability), 접근 정책을 중앙에서 투명하게 관리하는 기술이다. 이를 통해 개발자의 개입 없이도 인프라 계층에서 제로 트러스트 보안모델을 강제하고, 복잡한 분산 환경의 가시성을 확보하여 보안운영의 효율성을 극대화한다.
5-3. 불변 인프라(Immutable Infrastructure): '수정'이 아닌 '교체'를 통한 무결성 확보
과거처럼 관리자가 서버에 SSH로 접속해 설정을 '수정(Patch)'하는 방식은 사람의 실수나 보안 구멍을 남기기 쉽다. 불변 인프라는 한번 배포된 서버는 절대 건드리지 않고, 변경이 필요하면 아예 새로운 이미지로 인스턴스를 '교체(Replace)'하는 전략이다.
모든 인프라 상태가 코드(IaC)로 정의되어 깃(Git)에 남기 때문에 누가 언제 무엇을 바꿨는지 완벽하게 감사(Audit)할 수 있으며, 침해 사고 시에도 오염된 서버를 즉시 폐기하고 깨끗한 상태로 복구할 수 있어 보안 무결성을 보장한다.
6. 공급망 보안과 DevSecOps: 개발 단계부터 시작되는 보안 준수
6-1. 개발 파이프라인 보안 통합: DevSecOps와 Shift Left
현대적인 SaaS 개발에서 보안은 배포 직전의 '검사' 단계가 아니라, 개발의 시작부터 통합된 '문화'여야 한다. 이를 위해 CI/CD 파이프라인에 보안 자동화 도구를 심어, 취약점을 조기에 제거하는 DevSecOps 체계를 구축해야 한다.
SAST/DAST (애플리케이션 보안 테스팅): 소스 코드의 결함을 찾는 정적 분석(SAST)과 실행 중인 서비스의 취약점을 찾는 동적 분석(DAST)을 통해 코드를 다각도로 검증한다.
SCA (소프트웨어 구성 분석): 외부 오픈소스 라이브러리의 취약점(CVE)과 라이선스 리스크를 식별하여, 최근 급증하는 소프트웨어 공급망 공격을 예방한다.
컨테이너 스캐닝 (Container Scanning): 애플리케이션이 구동될 컨테이너 이미지 자체의 OS 취약점이나 설정 오류를 배포 전에 탐지한다.
정책 게이트(Policy Gate): 위 보안 검사 중 하나라도 기준을 통과하지 못하면(Fail), 배포 파이프라인을 자동으로 중단시켜 취약한 코드가 운영 환경에 나가는 것을 원천 봉쇄한다.
전 세계적인 보안 규제는 이제 단순한 방어가 아닌, 이처럼 설계 및 개발 단계부터 보안이 내재화된 구조를 강력하게 요구하고 있다.
6-2. SBOM: 소프트웨어의 구성 성분 표
SBOM(Software Bill of Materials)은 소프트웨어를 구성하는 모든 라이브러리 목록을 문서화한 것으로, EU CRA, NIS2, 미국 행정명령 등에서 요구하는 핵심 요소다.
아래 표는 미국 NTIA가 정의한 SBOM의 필수 요소로, 정확한 식별을 위한 데이터 필드, 기계 판독을 위한 자동화 지원, 그리고 지속적인 관리를 위한 버전이 유기적으로 결합되어야 유효한 SBOM임을 보여준다.
[그림 2. NTIA SBOM Core Elements Model (미국 NTIA 보고서)]
7. 운영 안정성과 감사 투명성: 규제의 마지막
7-1. 로그의 불변성(Immutable Logging) 데이터 무결성의 최종 방어선
보안 사고 발생 시 로그는 공격의 경로를 재구성(Forensics)할 수 있는 유일한 단서이자, 법적 효력을 갖는 핵심 감사 증적(Audit Trail)자료이다. 따라서 공격자에 의한 흔적 지우기나 내부자의 증거 인멸 시도를 막는 것은 보안의 기본이다.
이를 위해 WORM(Write Once Read Many) 기술을 스토리지에 적용하여, 한번 기록된 로그는 지정된 보존 기간 동안 누구도(Root관리자 조차) 수정하거나 삭제할 수 없도록 강제해야 한다. 이는 데이터의 무결성을 기술적으로 보증하며, ISMS-P나 GDPR 등 엄격한 컴플라이언스 요건을 충족하는 가장 확실한 수단이다.
7-2. 재해복구(DR) 및 운영 연속성: 가용성을 넘어선 탄력성
장애는 언제든지 발생할 수 있는 문제다. 따라서 단순히 데이터를 백업해 두는 수동적인 대응을 넘어, 물리적 재해나 랜섬웨어 공격에도 서비스가 멈추지 않는 운영 회복 탄력성을 확보해야 한다. 이를 위해 데이터센터 전체가 마비되어도 즉시 전환 가능한 멀티 AZ 이중화 아키텍처와 자동화된 복구 시스템이 필수적이다.
앞서 설명한 EU의 DORA(디지털 운영 회복탄력성법)는 금융 관련 SaaS 기업에게 단순한 계획 수립을 넘어, 실제 상황을 가정한 고강도 복구 훈련과 침투 테스트를 법적 의무로 부과하고 있다. 이제 고객은 사고 직후 서비스의 정상화와 고객 데이터 안전의 문제를 묻고 있다.
8. 결론: 규제 중심 설계는 SaaS의 신뢰도와 지속 가능성을 결정한다
전 세계 SaaS 규제는 표면적으로는 개인정보 보호, 금융 안정성, 사이버 보안 등 서로 다른 목적을 갖는 것처럼 보인다. 그러나 이를 기술적 요구사항으로 분해해 보면 공통된 구조적 기준을 반복적으로 요구하고 있음을 확인할 수 있다. 인증과 권한 관리가 명확하게 분리된 접근 통제 체계, 고객과 테넌트 단위로 격리된 데이터 보호 구조, 내부망과 외부망을 구분하지 않는 제로 트러스트 기반 네트워크 검증, 개발 단계부터 취약점과 공급망 리스크를 통제하는 보안 내재화, 그리고 모든 운영 행위를 사후에 입증할 수 있는 기록·감사 체계가 그것이다.
이 다섯 가지 축은 GDPR, NIS2, DORA, SOC 2(type II 포함), HIPAA, 국내 개인정보보호법과 금융 규제 등 개별 규제의 세부 조항을 넘어서는 공통 아키텍처 원칙에 가깝다. 특정 국가나 산업 규제에 맞춰 개별 대응을 반복하는 방식은 단기적으로는 가능할 수 있으나, 서비스 확장과 함께 복잡성과 운영 부담을 급격히 증가시킨다. 반대로, 설계 단계부터 이러한 공통 원칙을 반영한 SaaS는 규제 변화에도 비교적 안정적으로 대응할 수 있으며, 신규 시장 진입 시 요구되는 추가 비용과 시간을 크게 줄일 수 있다.
특히 최근의 규제 흐름은 ‘사고를 막았는가’보다 ‘사고가 발생했을 때 얼마나 통제되고 복구 가능한가’를 더 중시하는 경향을 보인다. 이는 정보보호가 더 이상 보안 기능의 집합이 아니라, 운영 체계 전반의 신뢰성과 복원력을 포함하는 개념으로 확장되고 있음을 의미한다. 접근 기록의 위·변조 방지, 변경 관리와 배포 이력의 추적성, 장애와 침해 사고에 대한 대응·보고 체계는 이제 선택 사항이 아니라 SaaS가 시장에 남기 위해 갖춰야 할 기본 요건이 되었다.
규제 대응은 흔히 비용이나 부담으로 인식되지만, 실제로는 SaaS 기업의 기술성숙도와 운영 역량을 외부에 객관적으로 증명할 수 있는 수단이 된다. 공공·금융·의료와 같이 진입 장벽이 높은 산업에서 요구되는 보안과 운영 기준을 충족하는 SaaS는, 일반 기업 시장에서도 자연스럽게 높은 신뢰를 확보할 수 있다. 이는 영업 단계에서 반복되는 보안 검증 부담을 줄이고, 장기 계약과 글로벌 확장의 기반을 마련하는 실질적인 경쟁력이 된다.
결국 SaaS 규제 대응의 핵심은 “법을 맞추는 것”이 아니라, 정보보호와 운영 안정성을 서비스의 기본 설계 요소로 내재화하는 것이다. 이러한 관점에서 설계된 SaaS만이 규제 환경의 변화 속에서도 신뢰를 유지하며, 국내를 넘어 글로벌 시장과 공공·금융 영역까지 지속적으로 확장할 수 있을 것이다.
참 고 문 헌
개인정보보호위원회. 개인정보 보호법 및 시행령, 시행규칙. 법령(2025년 개정)
ISMS-P 인증기준: 한국인터넷진흥원(KISA). 정보보호 및 개인정보보호 관리체계(ISMS-P) 인증기준.
과학기술정보통신부 · 한국인터넷진흥원. 클라우드 보안인증제(CSAP) 안내
전자금융감독규정 금융위원회. 전자금융거래법 및 전자금융감독규정.
금융분야 클라우드컴퓨팅 서비스 이용 가이드 (2025 개정) 금융보안원.
혁신금융서비스 지정 – SaaS 내부망 이용 승인(2024), 금융위원회 보도자료 / 전자신문.
GDPR (General Data Protection Regulation) European Union. Regulation (EU) 2016/679.
NIS2 Directive European Union. Directive (EU) 2022/2555.
DORA (Digital Operational Resilience Act) European Union. Regulation
EU Standard Contractual Clauses (SCCs) European Commission.
CCPA / CPRA (California Consumer Privacy Act) California Department of Justice.
HIPAA 보험연구원 조사자료
NIST SP 800-207 – Zero Trust Architecture NIST. (2020).
NIST SP 800-63B – Digital Identity Guidelines NIST.
SAML 2.0 Specification Single Sign-On을 위해 SAML 2.0 ID 공급자(Identity Provider)를 사용
OAuth2, OpenID Connect, 그리고 JWT 토큰 검증에 대해
SBOM – Minimum Elements: NTIA. The Minimum Elements for a Software Bill of Materials (SBOM).
EU Cyber Resilience Act (CRA) European Commission.
WORM (Write Once Read Many) Storage – Compliance Model AWS / Azure / Google Cloud Compliance Documentation.
Immutable Infrastructure 개념
저작권 정책
SaaS 전환지원센터 저작물인 『SaaS 보안 아키텍처 설계: 규제 대응』은 SaaS 전환지원센터에서 오픈인프라 한국 커뮤니티 김관영 부회장에게 집필 자문을 받아 발행한 전문정보 브리프로, SaaS 전환지원센터의 저작권정책에 따라 이용할 수 있습니다.
다만 사진, 이미지, 인용자료 등 제3자에게 저작권이 있는 경우 원저작권자가 정한 바에 따릅니다.
