SC-900 도메인 1(10~15%)은 비중이 작아 가볍게 넘기기 쉽지만, 공식 출제 범위에는 "암호화와 해싱", "ID 공급자", "디렉터리 서비스와 Active Directory", "페더레이션"이 각각 독립된 항목으로 적혀 있습니다. 문제도 "되돌릴 수 없는 변환은 무엇인가", "로그인에 성공한 사용자에게 토큰을 발급하는 것은 무엇인가"처럼 정의를 정확히 알아야 풀리는 형태로 나옵니다.
이 글은 그 네 가지 개념을 한 번에 정리합니다. 대칭·비대칭 암호화와 디지털 서명, 데이터 상태별 암호화와 키 관리, 해싱과 솔트, ID 공급자가 발급하는 토큰과 프로토콜, Active Directory Domain Services와 Microsoft Entra ID의 차이, 그리고 페더레이션의 신뢰 관계까지 차례로 살펴봅니다.
---
암호화: 키가 있어야 다시 읽을 수 있다
자물쇠로 잠근 상자는 누가 훔쳐 가도 열쇠가 없으면 내용물을 쓸 수 없습니다. 암호화도 데이터를 권한 없는 사람이 읽거나 쓸 수 없는 형태로 바꾸고, 다시 읽으려면 비밀 키로 복호화해야 합니다. 공격자가 암호화된 데이터를 가로채더라도 키가 없으면 쓸모가 없습니다.
대칭 암호화 vs 비대칭 암호화
| 구분 | 대칭 암호화 | 비대칭 암호화 | |------|------|------| | 키 | 암호화와 복호화에 같은 키 하나 | 공개 키와 개인 키 한 쌍 | | 속도 | 빠름, 대용량 데이터에 적합 | 상대적으로 느림 | | 약점과 장점 | 같은 키를 상대에게 안전하게 전달하기 어려움 | 공개 키는 마음껏 나눠 줄 수 있어 키 전달 문제를 해결 | | 대표 용도 | 디스크의 파일, 데이터베이스 레코드 | HTTPS, 이메일 암호화, 디지털 서명 |
비대칭 암호화에서는 공개 키로 암호화한 데이터를 짝이 되는 개인 키로만 풀 수 있습니다. 누구나 내 공개 키로 데이터를 잠가 보낼 수 있지만, 열 수 있는 사람은 개인 키를 가진 나뿐입니다. 공개 키에서 개인 키를 계산해 낼 수는 없습니다.
디지털 서명
비대칭 키를 반대 방향으로 쓰면 디지털 서명이 됩니다. 보내는 사람이 개인 키로 서명하면, 공개 키를 가진 누구나 두 가지를 확인할 수 있습니다.
정말 그 사람이 보냈는지 (진위성) 서명한 뒤 내용이 바뀌지 않았는지 (무결성)
소프트웨어 다운로드 검증, 이메일 인증, 전자 문서와 거래 보호에 쓰입니다.
데이터 상태별 암호화
| 상태 | 의미 | 보호 방법 | |------|------|------| | 저장 중 (at rest) | 디스크, 데이터베이스, 스토리지 계정에 저장된 데이터 | 저장 매체를 도난당해도 키 없이는 읽을 수 없게 암호화 | | 전송 중 (in transit) | 인터넷, 서비스 사이, 사설 네트워크로 이동하는 데이터 | TLS를 쓰는 HTTPS, VPN 연결 | | 사용 중 (in use) | 메모리에 올라가 CPU가 처리하는 데이터 | 기밀 컴퓨팅의 보호된 실행 환경(보안 엔클레이브) |
키 관리
암호화는 키만큼만 안전합니다. 키가 유출되면 암호화한 의미가 사라지므로 다음 원칙을 지킵니다.
키를 보호 대상 데이터와 분리해서 보관 변조에 강한 전용 하드웨어(HSM)에 저장 정기적으로 키를 교체(rotation) 강력한 인증과 최소 권한으로 키 접근을 통제
Azure Key Vault는 키, 인증서, 비밀을 한곳에서 관리하는 클라우드 키 관리 서비스입니다.
시험 팁: "같은 키로 잠그고 푼다"는 대칭, "공개 키로 잠그고 개인 키로 푼다"는 비대칭, "개인 키로 서명하고 공개 키로 확인한다"는 디지털 서명입니다.
---
해싱: 되돌릴 수 없는 지문
지문으로 그 사람이 맞는지 확인할 수는 있지만, 지문만 보고 그 사람의 얼굴을 다시 만들어 낼 수는 없습니다. 해싱은 어떤 입력이든 알고리즘으로 고정된 길이의 문자열(해시)로 바꾸는 단방향 변환입니다.
| 특징 | 설명 | |------|------| | 단방향 | 해시에서 원래 값을 되돌릴 수 없음 | | 결정적 | 같은 입력과 같은 알고리즘이면 항상 같은 해시 | | 고정 길이 | 입력이 한 글자든 책 한 권이든 해시 길이는 같음 | | 키 없음 | 암호화와 달리 키를 쓰지 않음 |
암호 저장과 솔트
시스템은 사용자의 실제 암호 대신 암호의 해시만 저장합니다. 로그인할 때 입력한 암호를 다시 해시해 저장된 값과 비교하므로, 데이터베이스를 통째로 도난당해도 공격자는 해시만 얻습니다.
다만 해시는 결정적이라서 공격자가 흔한 암호 수백만 개의 해시를 미리 계산해 둔 표(레인보 테이블)로 일치하는 값을 찾을 수 있습니다. 이를 막으려고 암호마다 무작위 값인 솔트(salt)를 덧붙여 해시합니다. 같은 암호를 쓰는 두 사용자도 해시가 서로 달라져, 미리 계산한 표가 쓸모없어집니다.
| 구분 | 암호화 | 해싱 | |------|------|------| | 키 사용 | 사용 | 사용 안 함 | | 원래 값 복원 | 키로 복호화 가능 | 불가능 | | 결과 길이 | 입력 크기에 따라 다름 | 항상 고정 | | 대표 용도 | 데이터를 숨겨서 저장·전송 | 암호 저장, 변조 여부 확인 |
!대칭 암호화, 비대칭 암호화, 해싱 한눈에 비교
시험 팁: "원래 값을 알 필요 없이 같은지만 확인"하는 상황이면 해싱입니다. Microsoft Entra Connect의 암호 해시 동기화도 실제 암호가 아니라 암호의 해시를 클라우드로 동기화합니다.
---
ID 공급자: 로그인을 대신 처리하는 곳
호텔은 손님의 신원을 직접 조사하지 않고 정부가 발급한 여권을 믿습니다. 현대 인증도 같습니다. 앱마다 사용자 계정과 암호를 따로 관리하는 대신, 전담 서비스인 ID 공급자(IdP)에게 인증을 맡깁니다.
ID 공급자는 ID 정보를 만들고 관리하며, 앱과 서비스에 인증·권한 부여·감사 기능을 제공합니다. 사용자가 앱에 로그인하려 하면 앱은 사용자를 ID 공급자로 보내고, ID 공급자가 자격 증명을 확인한 뒤 보안 토큰을 발급합니다. 앱은 ID 공급자를 신뢰하므로 이 토큰을 로그인 성공의 증거로 받아들입니다. Microsoft Entra ID가 Microsoft의 ID 공급자이고, Google이나 Facebook 계정으로 로그인하는 것도 같은 원리입니다.
토큰과 클레임
토큰에는 사용자 고유 ID, 이름과 이메일, 역할과 그룹, 발급·만료 시각 같은 정보 조각(클레임)이 담깁니다. 토큰은 시간이 지나면 만료되어 도난당해도 계속 쓸 수 없습니다.
| 토큰 | 의미 | 쓰임 | |------|------|------| | ID 토큰 | 사용자가 로그인에 성공했다는 증거 (인증) | 앱이 사용자가 누구인지 앎 | | 액세스 토큰 | 사용자를 대신해 특정 리소스에 접근할 권한 (권한 부여) | 일정 읽기, API 호출 등 |
표준 프로토콜
| 프로토콜 | 주된 역할 | 자주 쓰이는 곳 | |------|------|------| | OpenID Connect (OIDC) | 인증 | 최신 클라우드·모바일 앱 (OAuth 2.0 위에 구축) | | OAuth 2.0 | 권한 부여 | 액세스 토큰으로 보호된 리소스에 접근 | | SAML | 인증·페더레이션 | 기업용 앱, 오래된 앱, 조직 간 페더레이션 |
중앙 ID 공급자가 있으면 한 번 로그인으로 그 ID 공급자를 신뢰하는 모든 앱에 들어가는 SSO가 가능하고, ID 공급자에서 계정 하나를 사용 중지하면 연결된 모든 앱의 접근이 한 번에 끊깁니다.
시험 팁: 인증에는 OpenID Connect, 권한 부여에는 OAuth 2.0이 쓰인다는 구분이 자주 나옵니다. "토큰을 발급하는 주체"를 물으면 ID 공급자입니다.
---
디렉터리 서비스와 Active Directory
회사의 사원 명부와 출입 권한 대장을 한 권으로 합친 장부를 떠올려 보세요. 디렉터리는 네트워크의 사용자, 디바이스, 그룹, 정책, 애플리케이션 정보를 담은 저장소이고, 디렉터리 서비스는 이 정보를 저장하고 "이 사용자는 누구이며 어떤 그룹에 속하고 무엇에 접근할 수 있는가"에 답해 주는 소프트웨어입니다.
Active Directory Domain Services(AD DS)는 Windows 2000 Server부터 쓰인 Microsoft의 온프레미스 디렉터리 서비스이고, AD DS가 실행되는 서버를 도메인 컨트롤러라고 부릅니다. AD DS로 할 수 있는 일은 다음과 같습니다.
사용자당 ID 하나로 여러 온프레미스 시스템을 관리 그룹 정책으로 조직 전체 디바이스 설정을 통제 Kerberos와 NTLM으로 온프레미스 앱에 사용자 인증 조직 구성 단위(OU)로 사용자와 컴퓨터를 묶어 관리
하지만 AD DS는 회사 네트워크 안의 Windows PC를 전제로 설계되어, SaaS 앱 인증, iOS·Android 관리, OAuth 2.0·OpenID Connect 같은 최신 프로토콜, VPN 없는 원격 접속을 기본으로 지원하지 않습니다.
| 구분 | AD DS | Microsoft Entra ID | |------|------|------| | 위치 | 온프레미스 도메인 컨트롤러 | Microsoft가 운영하는 클라우드 서비스 | | 프로토콜 | Kerberos, NTLM, LDAP | OpenID Connect, OAuth 2.0, SAML | | 관리 방식 | 그룹 정책, 조직 구성 단위(OU) | 조건부 액세스, 앱 등록, 클라우드 정책 | | 잘 맞는 환경 | 회사 네트워크 안의 Windows 디바이스와 앱 | SaaS 앱, 모바일, 원격 근무 |
Entra ID는 "클라우드로 옮긴 AD DS"가 아닙니다. 도메인 가입, 그룹 정책, Kerberos가 필요한 오래된 앱을 클라우드로 옮길 때는 관리형 도메인 서비스인 Microsoft Entra Domain Services를 따로 씁니다. 두 환경을 함께 쓰는 하이브리드 ID는 Entra 인증 방법·암호 보호·하이브리드 ID에서 이어서 다룹니다.
시험 팁: "도메인 컨트롤러", "그룹 정책", "Kerberos"가 보이면 AD DS, "SaaS 앱 SSO", "OAuth"가 보이면 Entra ID입니다.
---
페더레이션: 다른 조직의 신분증을 믿어 주기
내 나라에서 발급한 여권을 다른 나라 입국 심사대가 인정해 주는 것처럼, 페더레이션은 서로 다른 ID 공급자 사이에 신뢰 관계를 맺어 사용자가 자기 조직의 자격 증명으로 다른 조직의 리소스에 접근하게 합니다. 상대 조직에 새 계정을 만들 필요가 없습니다.
기업 간 협업(B2B): 협력사 직원이 자기 회사 계정으로 공동 프로젝트 공간에 접근 소셜 ID 공급자: 소비자 앱에 Google, Microsoft, GitHub 계정으로 로그인 온프레미스 연동: Active Directory Federation Services(AD FS)로 온프레미스 인증을 클라우드 서비스까지 확장
시험 팁: 신뢰 관계는 자동으로 양방향이 되지 않습니다. A 조직이 B 조직을 신뢰한다고 해서 B 조직도 A 조직을 신뢰하는 것은 아니며, 양쪽 모두 접근해야 하면 양방향 신뢰를 따로 구성해야 합니다.
관련 글: 보안, 규정 준수, ID 핵심 개념