오픈인프라 한국 커뮤니티 / 김관영 부회장
그로메트릭 / 김관영 대표
1. 서론
Software-as-a-Service(SaaS) 모델은 설치·운영 부담 없이 브라우저와 API만으로 기업 핵심 업무를 처리할 수 있게 하면서 빠르게 확산되고 있다. 그러나 SaaS는 인터넷을 통해 불특정 다수의 사용자가 접속하고, 다수의 고객(테넌트)이 동일 인프라와 애플리케이션을 공유하는 멀티 테넌트 구조를 기반으로 하기 때문에, 신원 인증(Authentication)과 데이터 보호(Data Protection) 가 서비스 신뢰의 핵심 축으로 부상하고 있다.
특히 OAuth 2.0, OpenID Connect(OIDC), SAML 2.0과 같은 표준 기반 인증, 인가 프레임워크는 전 세계적으로 사실상 표준(de-facto standard)로 자리잡았으며, NIST SP 800-63B-4 Digital Identity Guidelines, ISO/IEC 27018, OWASP ASVS 등은 SaaS 환경에서 인증 강도, 식별자 관리, 데이터 보호 통제에 대한 기준을 제시하고 있다.
그러나 실제 멀티 테넌트 SaaS 아키텍처에서 이러한 표준과 가이드라인을 어떻게 해석 설계 운영할 것인지는 여전히 많은 조직의 과제로 남아 있다. 인증 표준을 단순 구현하는 수준을 넘어, 테넌트 경계, API 보안, 데이터 암호화, 키 관리, 규제 준수 요구사항을 통합적으로 다루는 보안 아키텍처 관점의 설계가 필요하다.
본 기고에서는 SaaS 환경에서의 보안 아키텍처를 인증(Authentication) 과 데이터 보호(Data Protection) 두 축으로 나누어 살펴보고, 멀티 테넌트 SaaS가 직면하는 위협과 한계를 분석한 뒤, 표준 기반 아키텍처 설계 방안과 실무적 시사점을 제시하고자 한다.
2. SaaS 보안 아키텍처 개요 및 위협 모델
2-1. 공유책임 모델과 멀티 테넌시 특성
퍼블릭 클라우드 및 SaaS 환경에서 보안은 클라우드 제공자, SaaS 사업자, 고객 간에 분담되는 공유 책임(Shared Responsibility) 모델을 따른다. 인프라 보안은 클라우드 사업자가, 애플리케이션과 데이터 보안은 SaaS 제공자와 고객이 함께 책임지는 구조다. 이때 SaaS 제공자는 다음 영역에 대한 주도적인 책임을 가진다.
- 사용자 및 테넌트 인증인가 체계
- 데이터 보호(암호화, 키 관리, 접근통제)
- 멀티 테넌시 데이터 격리
- 로그감사·침해 대응 체계: SIEM, Forensic 등
- 국내/국외 규제인증(예: ISMS-P, ISO 27001, ISO 27018, SOC 2 등) 대응
멀티 테넌트 SaaS의 가장 큰 특징은 물리, 논리적으로 동일한 인프라 위에 여러 테넌트의 데이터와 워크로드가 공존한다는 점이다. 따라서 인증과 데이터 보호는 곧 테넌트 경계(tenant boundary)를 정의하는 기술적 기초가 된다.
2-2. 대표 위협 모델
SaaS 보안 아키텍처 설계 시 고려해야 할 대표적인 위협은 다음과 같이 요약할 수 있다.
- 계정 탈취(Account TakeOver) 및 세션 하이재킹(Session Hijacking): 피싱, 자격 증명 대입(Credential Stuffing), 토큰 탈취 등으로 인한 불법 로그인
- 취약한 OAuth/OIDC 설정: Redirect URI 오용, 토큰 검증 누락, 동적 클라이언트 등록 오남용 등을 통한 권한 상승 및 계정 장악
- 테넌트 간 데이터 노출: 테넌트 식별자 오처리, 잘못된 쿼리 또는 접근제어 정책으로 인한 데이터 혼선
- TLS 암호화 미비 또는 키 관리 부실: 데이터 저장전송 시 암호화 미흡, 키·인증서 유출로 인한 대량 데이터 유출 위험
- 과도한 데이터 수집 및 보존: 최소 수집, 최소 보존 원칙 위반으로 인한 개인정보 대량 유출 시 피해 확산 방지
- 로그감사 미비: 접근 및 변경 내역을 충분히 남기지 않아 사고 발생 시 원인 추적 및 규제 대응 곤란
이러한 위협을 체계적으로 다루기 위해 인증 아키텍처와 데이터 보호 아키텍처를 분리하여 좀 더 세부적인 설계 원칙과 구현 전략을 확인해 보겠다.
3. 인증(Authentication) 아키텍처 설계
3-1. 표준 인증 프레임워크
(1) OAuth 2.0 ? 권한 위임 프레임워크
RFC 6749에서 정의된 OAuth 2.0은 제3자 클라이언트 애플리케이션이 자원 소유자를 대신해 제한된 접근 권한을 획득하도록 하는 인가(Authorization) 프레임워크이다.
- 주요 역할:
- Resource Owner: 데이터의 실제 소유자(사용자/테넌트)
- Client: SaaS 웹/모바일 앱, 외부 통합 애플리케이션
- Authorization Server: 인증인가 및 토큰 발급을 담당
- Resource Server: 보호된 API·리소스를 제공하는 서버
- 대표적인 인가 승인 타입:
- Authorization Code (인가 코드 방식)
- Implicit (메시지 요청회수를 줄이는 암묵적 방식)
- Resource Owner Password Credentials (리소스 소유자 비밀번호 자격 증명 방식)
- Client Credentials (클라이언트 자격 증명 방식)
SaaS에서는 주로 API 보안, 외부 통합, 서드파티 앱 연동에 OAuth 2.0을 활용하여, 사용자 비밀번호를 직접 공유하지 않고 토큰 기반으로 권한을 위임한다.
(2) OpenID Connect ? OAuth 위의 신원 계층
OpenID Connect Core 1.0은 OAuth 2.0 위에 신원 인증(Identity Layer)을 추가한 표준이다.
- OAuth 2.0의 Access Token에 더해, ID Token(JWT) 을 발급
- ID Token에는 사용자를 식별하는 subject, 발급자(iss), 대상(aud), 발급/만료 시간, 인증 시점 등을 포함
- 클라이언트는 ID Token 서명을 검증함으로써 “누가 로그인했는가?”를 신뢰성 있게 판단
SaaS 환경에서 OIDC는 다음과 같은 시나리오에 특히 적합하다.
- 기업 IdP(Okta, Microsoft Entra ID, Google Workspace 등)와의 SSO 연동
- 소셜 로그인(구글/네이버/카카오 등) 지원
- 멀티 테넌트 환경에서 테넌트별 IdP를 연동하는 페더레이션 구조
(3) SAML 2.0
SAML 2.0은 XML 기반의 엔터프라이즈 SSO 표준으로, 여전히 대규모 기업 환경에서 널리 사용된다.
SaaS 제공자는 SP(Service Provider) 로 동작하며, 기업의 IdP(Identity Provider) 와 신뢰 관계를 맺고 SAML Assertion 기반으로 로그인 세션을 수립한다.
SAML은 레거시 엔터프라이즈 환경과의 연동에 강점을 갖고, OIDC는 REST/JSON 기반 현대 SaaS와 높은 친화성을 가지므로, 많은 서비스가 두 표준을 병행 지원한다.
Tips) OAuth2와 OpenID Connect 중에서 선택하는 방법
둘 중 어떤 것을 선택할지는 웹 애플리케이션의 요구 사항과 목표에 따라 달라지며 사용자를 대신하여 리소스 서버의 리소스에 액세스하기만 하고 사용자의 신원이나 프로필에 관심이 없다면 OAuth2로 충분함. 사용자의 신원을 확인하고 기본 프로필 정보를 얻어야 하는 경우 OpenID Connect가 더 나은 선택일 수 있습니다. OAuth2를 기반으로 하는 OpenID Connect 권한 부여 코드 흐름 또는 암시적 흐름을 사용할 수 있지만, 액세스 토큰과 함께 ID 토큰을 반환할 수 있음
3-2. 인증 강도 및 수명주기 관리
[인증자 보증수준 레벨별 조건 설명]
NIST SP 800-63B-4 는 인증 수단 종류와 조합에 따라 인증보증단계(AAL, Authenticator Assurance Level) 을 정의하고, 각 수준에서 요구되는 인증 강도를 제시한다.
- AAL1: ID/비밀번호, OTP 등 단일 또는 낮은 수준의 인증자
- AAL2: 두 개 이상의 인증 요소(MFA) 및 승인된 암호 알고리즘 사용, Passkey 포함
- AAL3: 하드웨어 기반 인증기 등 가장 높은 신뢰 수준, 기기 기반 Passkey 포함
SaaS에서는 다음과 같이 수준별로 적용하는 전략이 유용하다.
- 일반 사용자 로그인: AAL1~2 (ID/PW + 소프트 OTP 등)
- 관리자보안 설정 변경: AAL2 이상 (FIDO2, 보안키, Push 기반 MFA 등)
- 금융의료·공공 데이터 접근: AAL2~3 수준의 강한 인증 요구
또한, 인증 수명주기 측면에서 다음 사항이 중요하다.
- 인증기 등록재발급·폐지 절차 정의
- 계정 잠금복구 프로세스에서 사회공학 공격 방지
- 장기 미사용 계정 자동 비활성화
- 토큰 만료, 갱신, 강제 무효화(Revocation) 정책
Tip) 아울러 NIST SP 800-63B-4에서는 기존의 "상식"을 뒤집는 새로운 요구사항을 제시하고 있음 예) 하지 말아야 할 것 - 정기적인 암호 변경 강제 금지
- 90일마다 비밀번호 변경을 강제하는 것은 더 이상 권장되지 않습니다.
- 침해의 증거가 있는 경우에만 변경을 요청해야 합니다.
- 이유: 자주 변경하면 사용자가 예측 가능하고 약한 비밀번호를 선택할 수 있습니다.
3-3. SSO 및 테넌트별 IdP 연동
엔터프라이즈 고객을 타깃으로 하는 B2B SaaS는 거의 필수적으로 SSO(Single Sign-On) 를 요구한다. 이를 위해 다음과 같은 아키텍처를 고려할 수 있다.
- 테넌트 메타데이터에 IdP 설정(메타데이터 URL, 클라이언트 ID/Secret, 인증 엔드포인트 등)을 저장
- 로그인 요청 시 테넌트 도메인 또는 subdomain을 기반으로 해당 테넌트의 IdP로 리디렉션
- IdP에서 발급한 OIDC ID Token 또는 SAML Assertion을 검증 후, 내부 테넌트 ID와 매핑하여 세션토큰 발급
이를 통해 SaaS는 테넌트별로 서로 다른 인증 정책(비밀번호 정책, MFA 필요 여부, 계정 잠금 기준 등)을 지원할 수 있으며, 고객 조직은 자사 IAM 체계를 그대로 유지하면서 SaaS를 도입할 수 있다.
3-4. MFA 및 Adaptive Authentication
단일 비밀번호 기반 인증은 피싱·크리덴셜 스터핑(Credential Stuffing) 공격에 취약하다. 이에 따라 SaaS에서는 다음과 같은 MFA 전략이 요구된다.
- 관리 콘솔, 보안 설정, 결제정보 변경 등 고위험 액션에 대해 추가 인증 요구
- 로그인 컨텍스트(지역, 디바이스, 시간대, IP 평판 등)을 기반으로 위험 점수를 산정하는 위험 기반(auth risk-based)으로 MFA 등 적용
- FIDO2/WebAuthn 기반 패스워드리스 패스키 인증 도입 적극 검토
Adaptive Authentication은 “모든 로그인에 동일한 강도의 보안을 강제하는 것”이 아니라 “위험도가 높을 때만 추가 인증을 유연하게 요구하는 것”으로, 보안과 UX의 균형을 맞추는 핵심 수단이다.
적응형 접근 제어의 3가지 예(출처 okta): 마이크라는 회계사를 상상해 보겠습니다. 그는 새크라멘토에 거주하며 귀사에서 10년간 근무했습니다. 그의 적응형 인증 경험이 어떤지 살펴보겠습니다.
시나리오 1
- 마이크의 프로필은 새크라멘토 시간으로 오전 8시에 회계 서버에 로그인을 시도합니다. 이 프로필은 30일 동안 동일한 요청을 해왔습니다.
- 시스템 응답: 비밀번호만 있으면 됩니다.
시나리오 2
- 마이크의 프로필은 새크라멘토 시간으로 새벽 2시에 회계 서버에 로그인을 시도합니다. IP 주소는 익숙하고 이전에도 사용된 적이 있습니다. 하지만 이 프로필은 밤에 로그인한 적이 없습니다.
- 시스템 응답: 비밀번호와 마이크의 인증된 휴대폰으로 전송된 코드가 필요합니다.
시나리오 3
- 마이크의 프로필은 새크라멘토 시간으로 오전 2시에 익숙하지 않은 IP 주소에서 마케팅 서버에 로그인을 시도합니다.
- 시스템 응답: 비밀번호, 보조 코드, 지문을 통한 생체 인증이 모두 필요합니다.
3-5. AI의 API, M2M머신 간 인증 및 권한 관리
SaaS는 내부 마이크로서비스, 외부 통합, 파트너 API 등 머신 간 통신(M2M) 이 광범위하게 활용된다. 이 경우 사람 사용자와 다른 다음 요소를 설계해야 한다.
- Client Credentials Grant 기반 M2M 토큰 발급
- Micro Service 간의 mTLS 및 서비스 계정(Service Account) 관리
- 토큰에 포함되는 Scope, Audience를 최소 권한 원칙(Least Privilege)에 따라 설계
- RBAC(Role-Based Access Control), 필요 시 ABAC(Attribute-Based Access Control) 적용
OWASP ASVS는 인증·세션·액세스 제어에 대한 구체적 검증 항목을 제공하므로, SaaS 개발·검증 시 체크리스트로 활용할 수 있다. ASVS 에서도 NIST에서 규정한 3단계의 Assurance Level을 채택하고 있다.
4. 데이터 보호(Data Protection) 아키텍처 설계
4-1. 데이터 분류 및 민감도 기반 설계
데이터 보호 전략의 출발점은 데이터 분류(Data Classification) 이다. 일반적으로 다음과 같이 민감도를 구분할 수 있다.
- 공개 정보: 마케팅 페이지, 공개 문서 등
- 내부 정보: 운영 로그, 일반 설정 값 등
- 민감 정보: 고객 계약, 내부 재무 정보
- 개인정보/PII: 이름, 이메일, 전화번호, 로그에 포함된 식별자 등
- 민감 PII/특수 유형 정보: 건강, 금융, 위치, 인증 정보 등
각 등급에 따라 저장 및 전송 암호화, 접근 통제, 보존 기간, 마스킹, 가명처리 수준을 차등 적용하는 것이 바람직하다.
ISO/IEC 27018은 퍼블릭 클라우드 환경에서 PII 보호를 위한 통제 목표와 권고 사항을 제시하고 있으며, SaaS 제공자가 개인정보 처리자로서 어떤 통제를 구현해야 하는지 방향성을 제공한다.
4-2. 전송 구간 암호화
SaaS 트래픽은 기본적으로 인터넷을 거쳐 전송되므로, 전송 중 데이터 보호를 위한 암호화는 필수다.
- 외부 트래픽: TLS 1.2 이상(1.3 권고) 강제, 강력한 Cipher Suite 선택, HSTS(HTTP Strict Transport Security) 적용
- 내부 마이크로서비스 간 트래픽: mTLS를 통한 상호 인증, 서비스 메시(Istio, Linkerd 등) 활용 시 정책 기반으로 mTLS 일괄 적용
- API 호출: OAuth Access Token 및 ID Token은 반드시 TLS 위에서만 전송
또한, 토큰·쿠키·세션 ID는 안전한 쿠키의 속성 값(HTTPOnly, Secure, SameSite)과 짧은 만료 시간 설정을 통해 탈취 위험을 줄여야 한다.
4-3. 저장 데이터 암호화와 키 관리
저장 데이터 보호는 크게 스토리지/디스크 수준 암호화와 애플리케이션/컬럼 수준 암호화로 나눌 수 있다.
- 디스크/볼륨 암호화: 클라우드 제공자의 KMS를 활용한 스토리지 암호화(EBS, RDS, Blob 스토리지 등)
- 컬럼/필드 수준 암호화: 주민번호, 계좌번호, 토큰, 인증정보 등 민감 필드를 애플리케이션 레벨에서 별도 암호화
- 해시/단방향 처리: 비밀번호는 적절한 해시 함수(BCrypt, PBKDF2 등)로 저장, 비밀번호나 인증정보를 원문 복원 불가능한 형태로 변환
키 관리 관점에서 다음 사항이 중요하다.
- 키 인증서 비밀정보를 코드 리포지토리나 컨테이너 이미지에 포함하지 않고, 전용 비밀 관리 시스템(Cloud KMS, Vault, HSM, Secrets Manager 등)에 보관
- 키 수명주기(발급, 회전, 폐기) 정책 수립
- 키 접근 통제를 RBAC와 연계하여 최소 권한으로 제한
4-4. 멀티 테넌시 데이터 격리 전략
멀티 테넌트 SaaS에서 데이터 보호의 핵심은 테넌트 간 논리적·물리적 격리이다. 대표적인 데이터 모델 전략은 다음과 같다.
- 공유 DB + 테넌트 구분 컬럼: 하나의 DB/테이블에 Tenant index 컬럼으로 구분
- 테넌트별 스키마 분리: 하나의 DB 인스턴스에 테넌트별 별도 스키마
- 테넌트별 별도 DB 인스턴스: 보안규제 요구가 높은 VIP 고객 등에게 제공하는 모델
공유 DB 모델을 사용할 경우 반드시 다음을 보장해야 하며 필요시 ORM등 추가적인 사항도 검토
- 모든 쿼리가 Tenant index 컬럼 조건을 포함하도록 애플리케이션 레벨에서 강제
- ORM(Object-Relational Mapping) 레벨에서 글로벌 Filter/Scope를 적용하여 개발자 실수를 방지
- OIDC/OAuth 토큰에 테넌트 정보(tenant index / organization index)를 포함하고, 이를 기반으로 접근 범위를 제한
또한, 백업·복구 시에도 개별 테넌트 또는 전체 테넌트의 데이터가 어떻게 복구되는지, 테넌트 삭제 시 데이터 완전 삭제, 가명처리 전략이 어떻게 되는지 명확히 설계해야 한다.
4-5. 로그 감사 프라이버시 보호
SaaS는 규제 및 포렌식 요구 대응을 위해 접근 로그, 변경 로그, 관리자 행위 로그를 상세하게 남겨야 한다. 동시에 로그 안에 과도한 PII가 포함되어 프라이버시 리스크를 키우지 않도록 하는 절충이 필요하다.
- 감사 로그: 로그인, 인증 실패, MFA 실패, 권한 상승, 설정 변경, 데이터 내보내기(export) 등의 이벤트를 추적
- PII 최소 기록: 로그에는 식별자가 꼭 필요할 때만 포함하고, 가능하면 해시 가명처리
- 보존 기간: 규제(예: ISMS-P)와 비즈니스 요구에 맞는 최소한의 보존 기간 설정 후 자동 파기
OWASP ASVS V7(Error Handling and Logging Verification Requirements)는 로깅·감사 항목과 관련된 구체적인 통제 요구사항을 제시하고 있으며, 이를 기반으로 SaaS 로그 체계를 설계할 수 있다.
- 1 Log Content Requirements ? 무엇을 로그에 남길 것인가
- 2 Log Processing Requirements ? 로그를 어떻게 수집·전송·처리 할 것인가
- 3 Log Protection Requirements ? 로그를 어떻게 보호 할 것인가
- 4 Error Handling ? 에러 메시지와 예외를 어떻게 처리 할 것인가
로그는 민감 정보를 직접 남기지 않고 접근·행위·결과 중심으로 기록하며, 서비스 전반의 보안·운영 이벤트를 통합 집계해 분석·알림 체계를 구축하고, 그 로그 자체도 중요 자산으로 간주해 강력한 암호화·접근통제를 적용해야 한다.
4-6. 백업 및 재해복구 관점의 데이터 보호
데이터 보호는 평상시의 접근통제뿐 아니라 장애·재해 상황에서의 복원력까지 포함한다.
- 정기적 스냅샷 및 백업 정책 수립 RTO(Recovery Time Objective) / RPO(Recovery Point Objective) 정의
- 백업 데이터에 대한 별도 암호화 및 접근 통제
- 특정 테넌트 데이터만 복구해야 하는 경우를 대비한 테넌트 단위의 복구 전략
- 다중 리전 또는 가용영역에 대한 복제 구성
데이터 복구 과정에서도 인증·권한 검증을 우회하지 않도록, 운영자용 콘솔 및 스크립트에 대한 강력한 접근통제가 필요하다.
5. 주요사례 분석을 통한 시사점
5-1. 잘못된 인증 및 토큰 처리로 인한 사고 교훈
최근 공개된 여러 연구와 실제 사고 사례는 OAuth/OIDC 구현 시 다음과 같은 취약점이 반복적으로 등장하고 있음을 보여준다.
- Redirect URI 검증 미흡으로 인한 코드 탈취
- 토큰 서명 키 노출 또는 잘못된 검증 로직(alg=none 허용은 검증로직 우회)
- 동적 클라이언트 등록 기능을 악용한 SSRF, 계정 하이재킹
- 세션 관리 부실로 인한 로그아웃 후 재접속, 토큰 재사용:
다크웹에는 전세계 940억개의 쿠키가 유출되어 있음(기사 "전 세계 940억개 웹쿠키 다크웹 유출…한국 5.7억개로 34위")
이러한 사례는 표준을 사용한다고 해서 자동으로 안전해지는 것이 아니라, 표준에서 요구하는 보안 고려사항을 정확히 구현하고, 정기적인 보안 테스트와 코드 리뷰를 수행해야 함을 보여준다.
5-2. 데이터 보호 및 프라이버시 관련 글로벌 동향
NIST, ISO, OWASP 등 다양한 국제 표준과 프레임워크는 SaaS 데이터 보호에 대한 기준을 지속적으로 갱신하고 있다.
- NIST SP 800-63B-4: 디지털 신원, 인증 강도, 수명주기 관리에 대한 구체적인 가이드라인 제공
- ISO/IEC 27018: 퍼블릭 클라우드 환경에서 PII 보호를 위한 통제 목표와 세부 통제 항목 정의
- OWASP ASVS: 애플리케이션 레벨에서 데이터 보호, 암호화, 로그 관리 등 검증 항목 제공
SaaS 제공자는 이러한 글로벌 기준을 참고하여 내부 보안 아키텍처 원칙과 기술 표준을 수립하고, 필요 시 외부 인증(ISO, SOC 2, ISMS 등)을 통해 시장 신뢰를 확보할 수 있다.
6. 결론
본 기고에서는 멀티 테넌트 SaaS 환경에서 인증(Authentication) 과 데이터 보호(Data Protection) 를 중심으로 보안 아키텍처 설계 방향성을 함께 살펴보았다.
첫째, 인증 측면에서 OAuth 2.0과 OIDC(OpenID Connect), SAML 2.0 등 표준 기반 인증·인가 프레임워크를 활용하여 IdP 연동, SSO, M2M 통신을 안전하게 구현하고, NIST SP 800-63B-4가 제시하는 인증 강도(AAL)에 맞춘 MFA, 패스워드리스, 위험 기반 인증 전략을 적용하는 것이 중요함을 확인했다.
둘째, 데이터 보호 측면에서 데이터 분류, 전송·저장 암호화, 키 관리, 멀티 테넌시 데이터 격리, 로그·감사 및 백업·복구 전략을 통합적으로 설계해야 하며, ISO/IEC 27018, OWASP ASVS 등 글로벌 기준을 참고하여 PII와 민감 데이터를 보호하는 것이 필요함을 살펴보았다.
셋째, 실제 사고 사례와 연구를 보면, 표준을 사용하더라도 잘못된 구현·설정으로 인해 OAuth/OIDC 취약점, 토큰 탈취, 테넌트 간 데이터 노출이 반복되고 있다. 따라서 표준 및 규정 준수와 더불어 구현 품질, 운영 프로세스, 정기적인 보안 검증이 함께 필요하다.
향후 과제로는 다음과 같은 영역이 남아 있다.
- 사용자뿐 만 아니라 디바이스 레벨까지 포함된 인증보증 수준 3단계 및 행위 정보를 통합한 제로 트러스트(Zero Trust) 기반 인증인가 아키텍처 고도화
- AI/ML 기반 이상 행위 탐지와 인증 리스크 평가 적용 모델 도입: 리스크 기반 인증(Risk-Based Authentication, RBA) 적용 등
- SBOM, 공급망 보안, 규제 대응(예: EU CRA, NIS2)와 연계된 SaaS 보안 아키텍처 통합 연구
SaaS 보안 아키텍처는 서비스의 신뢰와 비즈니스의 지속 가능성을 좌우하는 핵심 설계 요소다. 인증과 데이터 보호를 체계적으로 설계·운영하는 조직만이, 멀티 테넌트·멀티 클라우드 시대에 고객과 시장의 신뢰를 확보할 수 있을 것이다.
참 고 문 헌
- https://www.okta.com/openid-connect/:
- https://devocean.sk.com/blog/techBoardDetail.do?ID=165453&boardType=techBlog
- https://docs.aws.amazon.com/ko_kr/IAM/latest/UserGuide/id_roles_providers_saml.html
- https://datatracker.ietf.org/doc/html/rfc6749
- https://openid.net/specs/openid-connect-core-1_0.html
- https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63B-4.pdf
- https://owasp.org/www-project-application-security-verification-standard/
- https://github.com/OWASP/ASVS
- https://portswigger.net/research/hidden-oauth-attack-vectors
- https://unit42.paloaltonetworks.com/oidc-misconfigurations-in-ci-cd/
- https://www.cloudflare.com/ko-kr/learning/access-management/what-is-saml/
- https://www.sakimura.org/ko/2025/10/7710/
- https://www.corbado.com/blog/nist-passkeys
- https://www.iso.org/standard/27018
- https://www.yna.co.kr/view/AKR20250527046900017)
저작권 정책
SaaS 전환지원센터 저작물인 『SaaS 보안 아키텍처 설계: 인증, 데이터 보호』은 SaaS 전환지원센터에서 오픈인프라 한국 커뮤니티 김관영 부회장에게 집필 자문을 받아 발행한 전문정보 브리프로, SaaS 전환지원센터의 저작권정책에 따라 이용할 수 있습니다.
다만 사진, 이미지, 인용자료 등 제3자에게 저작권이 있는 경우 원저작권자가 정한 바에 따릅니다.