CompTIA SY0-701: 신원 및 접근 관리 — 학습 가이드

By Laurynas Brazys · 20 July 2026 · #comptia #sy0-701 #certification #exam-prep #study-guide

다음의 일부입니다: CompTIA Security+ SY0-701 — 학습 가이드. 검증된 답안으로 연습하기: CompTIA 시험 허브, 또는 다음에서 시간 제한 모의고사 풀기: ExamRoll.io.

ID 및 액세스 관리(IAM)는 올바른 주체(사용자, 서비스, 디바이스)가 올바른 리소스에 올바른 시간에 필요한 기간 동안만 올바른 액세스 권한을 얻도록 보장하는 분야입니다. 이는 개념적으로 구별되는 두 가지 핵심 요소에 기반하지만, 이 둘은 자주, 그리고 위험하게 혼동됩니다. 바로 주체가 누구인지 증명하는 인증과, 인증된 주체가 무엇을 할 수 있는지 결정하는 권한 부여입니다. 사용자가 지문으로 워크스테이션에 로그인하는 것은 인증에 해당하며, 그 사용자가 급여 데이터베이스를 열 수 있는지 여부는 권한 부여의 문제입니다. 이 둘의 경계를 모호하게 만드는 제어 설계는 보안 침해를 유발할 수 있습니다.

인증 요소와 다중 인증

인증 요소는 전통적으로 다섯 가지 범주로 분류됩니다: 알고 있는 것(비밀번호, PIN), 가지고 있는 것(스마트카드, 하드웨어 토큰, TOTP 앱이 설치된 휴대폰), 신체적 특징(지문, 망막, 얼굴 형태), 있는 위치(지리적 위치 또는 네트워크 기반 컨텍스트), 그리고 하는 행동(타이핑 주기와 같은 행동 생체 인식). 다중 인증(MFA)은 최소 두 가지 다른 범주의 증거를 요구합니다. 비밀번호와 보안 질문을 함께 사용하는 것은 MFA가 아닙니다. 둘 다 “알고 있는 것"에 속하기 때문입니다. 비밀번호와 Google Authenticator의 TOTP 코드를 함께 사용하는 것이 MFA입니다.

하드웨어 토큰은 여러 형태가 있습니다. YubiKey와 같은 FIDO2/WebAuthn 보안 키는 비대칭 암호화를 사용합니다. 개인 키는 절대 디바이스를 떠나지 않으며, 서버는 공개 키만 보유하므로 피싱과 재전송 공격을 방어할 수 있습니다. HOTP 토큰은 카운터를 기반으로 일회용 비밀번호를 생성하고, TOTP 토큰은 현재 시간을 기반으로 HMAC-SHA1 구조를 사용하여 생성합니다.

TOTP = HMAC-SHA1(shared_secret, floor(current_unix_time / 30))

정부 환경에서 흔히 사용되는 PIV나 CAC 카드 같은 스마트카드는 변조 방지 칩에 X.509 인증서와 개인 키를 저장합니다. 카드를 제시하고 PIN을 입력하면 두 가지 요소를 충족하여, Kerberos PKINIT를 통해 Active Directory와 같은 시스템에 인증서 기반 인증을 할 수 있습니다.

MFA는 자격 증명 도용에 대한 가장 효과적인 단일 제어 수단입니다. 사용자가 자신이 시작하지 않은 IP 주소에서의 로그인을 보고할 때, 비밀번호를 재설정하는 것은 증상을 해결하는 것이지만, MFA를 강제하는 것은 근본 원인을 해결하는 것입니다. 도난당한 비밀번호만으로는 더 이상 충분하지 않기 때문입니다.

싱글 사인온과 페더레이션

싱글 사인온(SSO)은 사용자가 한 번 인증하면 자격 증명을 다시 입력하지 않고도 여러 애플리케이션에 액세스할 수 있게 해줍니다. 페더레이션은 이를 조직이나 신뢰 경계를 넘어 확장하는 개념으로, 한 도메인의 ID 공급자(IdP)가 다른 도메인의 서비스 공급자(SP)에게 사용자를 보증해주는 방식입니다. 여기서 가장 흔한 오해는 SAML과 OAuth를 서로 바꿔 쓸 수 있는 것으로 취급하는 것인데, 이 둘은 서로 다른 문제를 해결합니다.

SAML 2.0은 엔터프라이즈 SSO 및 인증 어설션을 위해 설계된 XML 기반 프로토콜입니다. 사용자가 SaaS 애플리케이션을 요청하면, SP는 브라우저를 IdP로 리디렉션합니다. IdP는 사용자를 인증하고 ID 속성이 포함된 서명된 SAML 어설션을 반환합니다. 이는 직원들이 기업의 Active Directory 자격 증명을 사용하여 Salesforce나 Workday 같은 클라우드 애플리케이션에 액세스할 수 있도록 하는 표준 메커니즘입니다.

OAuth 2.0은 인증 프로토콜이 아닌 권한 부여 프레임워크입니다. 이는 제3자 애플리케이션이 액세스 토큰을 통해 사용자를 대신하여 리소스에 대한 위임된 액세스 권한을 부여받도록 합니다. 애플리케이션이 여러분의 Twitter 피드에 게시하도록 허용하는 것이 OAuth 흐름의 예입니다. **OpenID Connect(OIDC)**는 OAuth 2.0 위에 구축된 ID 계층으로, 인증 어설션을 제공하는 id_token(JWT)을 추가합니다. “Google로 로그인” 기능이 가능한 것은 바로 이 때문입니다.

중요한 함정: SSO와 페더레이션은 자격 증명 난립을 줄여주지만, MFA의 필요성을 제거하지는 않습니다. 오히려 위험을 한 곳에 집중시키는 결과를 낳습니다. 하나의 SSO 자격 증명이 손상되면 모든 페더레이션된 애플리케이션의 잠금이 해제되기 때문입니다. MFA는 IdP에서 강제되어야 하며, 권한 있는 계정은 SSO 이후에도 스텝업 인증을 요구해야 합니다.

액세스 제어 모델

ID가 설정되면, 액세스 제어 모델이 권한 부여 결정을 관리합니다. **임의적 액세스 제어(DAC)**는 리소스 소유자가 일반적으로 액세스 제어 목록(ACL)을 통해 권한을 설정하도록 합니다. **강제적 액세스 제어(MAC)**는 레이블과 클리어런스를 기반으로 정책을 중앙에서 강제하며, 군사 시스템에서 흔히 사용되고 SELinux와 같은 프레임워크에 의해 시행됩니다. **역할 기반 액세스 제어(RBAC)**는 권한을 역할에 할당하고 사용자를 역할에 할당합니다. “청구 분석가” 역할은 정의된 권한 집합을 가지며, 사용자는 역할 멤버십을 통해 권한을 상속받습니다. **속성 기반 액세스 제어(ABAC)**는 주체, 리소스, 작업 및 환경의 속성에 대해 정책을 평가하여 “업무 시간 동안 회사 관리 디바이스에서만 HR 파일에 대한 읽기 액세스 허용"과 같은 규칙을 가능하게 합니다.

모든 모델의 상위에는 최소 권한 원칙이 있습니다. 주체는 자신의 기능을 수행하는 데 필요한 최소한의 액세스 권한만 부여받고, 그 이상은 받지 않습니다. 이를 보완하는 것이 직무 분리로, 한 개인이 민감한 전체 프로세스를 통제하는 것을 방지합니다. 즉, 결제를 요청하는 사람과 승인하는 사람이 달라야 합니다.

실용적인 액세스 제어에는 파일 시스템 ACL, 라우터 및 방화벽의 네트워크 ACL, 그리고 허가된 시간 동안만 로그인을 허용하는 시간대 제한 등이 있습니다. 재무 공유 폴더에 읽기 전용 액세스를 부여하는 Windows ACL 항목은 다음과 같을 수 있습니다.

icacls C:\Finance /grant "Domain\Finance-RO:(OI)(CI)R"

권한 있는 액세스 관리(Privileged Access Management)

권한 있는 계정(도메인 관리자, root, 데이터베이스 시스템 관리자, 클라우드 루트 계정, 서비스 계정)은 모든 환경의 핵심 자산입니다. 권한 있는 액세스 관리(Privileged Access Management, PAM) 시스템(예: CyberArk, BeyondTrust, HashiCorp Vault)은 이러한 계정에 대한 통제를 강화합니다. 즉, 자격 증명은 자동으로 보관(vaulted) 및 교체되고, 세션은 기록되며, 체크아웃 시에는 사유 제출과 종종 승인이 필요하고, 암호는 일회용이거나 임시적인 경우가 많습니다.

Just-in-time (JIT) 액세스는 특정 작업 기간에만 권한을 상승시켜 상시 관리자 권한을 제거합니다. 데이터베이스 마이그레이션을 실행해야 하는 개발자는 30분 후에 자동으로 만료되는 시간 제한적 자격 증명을 받습니다. 탈취당할 영구적인 권한 있는 계정이 존재하지 않는 것입니다. Azure AD의 **PIM(Privileged Identity Management)**은 이러한 패턴을 기본적으로 구현하여, 권한 상승 전에 승인 워크플로와 MFA 재인증을 요구합니다.

서비스 계정은 또 다른 과제입니다. 이 계정들은 종종 과도한 권한을 가지며, 암호는 거의 교체되지 않고, 사용 현황은 거의 감사되지 않습니다. Active Directory의 MSA(Managed Service Accounts) 및 gMSA(Group Managed Service Accounts)는 암호 교체를 자동화하고 사람이 서비스 계정 자격 증명을 알 필요가 없게 만듭니다.

디렉터리 서비스 및 프로비저닝

**Active Directory (AD)**는 여전히 온프레미스 환경의 지배적인 자격 증명 저장소입니다. 사용자, 컴퓨터, 그룹은 OU(Organizational Units)로 구성되며, GPO(Group Policy Objects)는 구성 및 보안 설정을 계층적으로 적용합니다. AD 트러스트는 도메인과 포리스트 간에 인증을 확장합니다. **Azure Active Directory (Entra ID)**는 이러한 개념을 클라우드로 확장하여 조건부 액세스 정책, ID 보호 위험 점수화, 수천 개의 SaaS 애플리케이션과의 원활한 통합 기능을 추가합니다.

LDAP(Lightweight Directory Access Protocol)는 디렉터리 서비스를 쿼리하기 위한 기본 프로토콜입니다. RADIUS는 네트워크 액세스를 위한 인증을 중앙 집중화합니다. VPN, Wi-Fi, 802.1X 유선 인증은 모두 일반적으로 AD를 백엔드로 사용하는 RADIUS 서버에 대해 인증합니다. **TACACS+**는 네트워크 장비 관리를 위해 비슷한 역할을 수행하며, 인증, 권한 부여, 계정 관리를 별개의 단계로 분리하는 추가적인 이점이 있습니다.

사용자 프로비저닝 및 디프로비저닝은 HR 프로세스와 긴밀하게 연결되어야 합니다. 가장 고질적인 IAM 실패 사례는 고아 계정(orphaned account)입니다. 즉, 퇴사 후 몇 주 또는 몇 달 동안 Active Directory 계정이 활성 상태로 남아 있는 전 직원의 계정입니다. SCIM(System for Cross-domain Identity Management) 또는 HR-AD 커넥터를 통한 자동화된 프로비저닝을 의무적인 디프로비저닝 체크리스트와 결합하면 이러한 격차를 해소할 수 있습니다.

실제 시나리오: 고아 계정을 통한 자격 증명 침해

한 제조 회사의 IT 팀은 현재는 중단된 통합 프로젝트를 위해 생성되었던 서비스 계정에서 업무 시간 외에 ERP 시스템으로 비정상적인 액세스가 있었음을 발견했습니다. 이 계정은 도메인 사용자 권한을 가지고 있었고, 특정 직원과 연결되어 있지 않았기 때문에 분기별 액세스 검토에서 한 번도 검토된 적이 없었습니다. 다크웹 덤프에서 자격 증명을 구매한 공격자는 이 계정을 사용하여 파일 공유를 열거하고, 가격 데이터를 유출했으며, 예약된 작업을 통해 영구적인 거점을 확보했습니다. 이 침해 사고는 ERP 공급업체가 비정상적인 API 호출 패턴을 발견하고 나서야 드러났습니다. 근본 원인은 실패한 디프로비저닝 프로세스였습니다. 통합 프로젝트는 해제되었지만 계정은 비활성화되지 않았던 것입니다. 고아 계정의 자동 탐지 및 의무적인 검토 주기를 갖춘 PAM 시스템을 구현했다면 이 계정은 악용되기 훨씬 전에 발견되었을 것입니다.

← 거버넌스 · 모든 도메인 · 위협 →

이 문제 연습하기 → · ExamRoll.io에서 시간 제한 연습 →