CompTIA SY0-701: 데이터 보안, 개인정보 보호 및 암호학 — 학습 가이드

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

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

대부분의 공격에서 데이터는 최종 표적이 되며, 암호화는 전송 중, 저장 시, 사용 중인 데이터를 보호하는 핵심 기술 메커니즘입니다. 암호화 기본 요소의 속성, 한계, 올바른 적용법을 이해하는 것은 시험뿐만 아니라, 개별 통제가 실패했을 때도 보안을 유지하는 시스템을 설계하는 데 있어 기초가 됩니다.

데이터 분류 및 처리

데이터 분류는 민감도 레이블을 할당하여 데이터 처리 요구사항을 결정합니다. 정부 프레임워크는 Unclassified, Confidential, Secret, Top Secret을 사용합니다. 상용 프레임워크는 일반적으로 Public, Internal, Confidential, Restricted(또는 이와 동등한 등급)를 사용합니다. 분류는 편의성이 아니라 데이터의 민감도와 규제 의무에 따라 결정되어야 합니다.

데이터 유출 방지(Data Loss Prevention, DLP) 시스템은 엔드포인트, 네트워크 출구 지점, 클라우드 스토리지의 콘텐츠를 검사하여 처리 정책을 시행합니다. 예를 들어, DLP 규칙은 신용카드 패턴과 일치하는 16자리 문자열이 포함된 이메일 첨부 파일을 차단하거나, 사용자가 “인수 대상"이라는 문구가 포함된 파일을 개인 클라우드 스토리지 서비스에 업로드할 때 경고를 보낼 수 있습니다. DLP의 효과는 정확한 분류에 달려 있습니다. 민감한 데이터에 레이블이 지정되지 않으면 DLP는 이를 보호할 수 없습니다.

**데이터 주권(Data sovereignty)**은 데이터가 물리적으로 어디에 위치하고 어느 사법권의 법률이 적용되는지에 대한 문제입니다. GDPR은 EU 외부로 전송되는 EU 개인 데이터가 적정성 결정, 표준 계약 조항 또는 구속력 있는 기업 규칙에 의해 보호되도록 요구합니다. 전 세계적으로 운영되는 조직은 데이터 흐름을 파악하고 스토리지 및 처리 위치가 관련 규정을 준수하는지 확인해야 합니다.

전송 중 암호화 및 저장 데이터 암호화

TLS 1.3은 전송 중인 데이터를 암호화하는 현재 표준입니다. 취약한 암호화 스위트를 제거하고, 순방향 비밀성(ephemeral Diffie-Hellman 키 교환)을 의무화하며, 핸드셰이크를 단일 왕복으로 줄입니다. TLS 1.0과 1.1은 더 이상 사용되지 않으며, TLS 1.2는 여전히 허용되지만 강력한 암호화 스위트로 구성해야 합니다. 현재 표준을 적용하는 Nginx 구성은 다음과 같습니다.

# Enforcing TLS 1.2+ in an Nginx server block
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384;
ssl_prefer_server_ciphers on;

**저장 데이터 암호화(Encryption at rest)**는 스토리지 미디어의 데이터를 보호합니다. 전체 디스크 암호화(BitLocker, FileVault, LUKS)는 전체 볼륨을 암호화하고, 파일 수준 암호화(EFS, VeraCrypt 컨테이너)는 개별 파일을 암호화합니다. 데이터베이스 수준 암호화(SQL Server 및 Oracle의 Transparent Data Encryption)는 데이터 파일과 백업을 암호화합니다. 여기서 중요한 점은, 저장 데이터 암호화는 물리적 미디어 도난으로부터는 보호하지만, 이미 데이터를 복호화하여 처리 중인 손상된 애플리케이션으로부터는 보호하지 못한다는 것입니다.

암호화 기본 요소

대칭 알고리즘(AES-128, AES-256, ChaCha20)은 하나의 공유 키를 사용하며 속도가 빨라 대량 데이터 처리에 적합합니다. 비대칭 알고리즘(RSA, ECDSA, Ed25519, ECDH)은 키 쌍을 사용하며 키 교환, 디지털 서명, 신원 바인딩을 가능하게 하지만 계산 비용이 많이 듭니다. TLS와 같은 하이브리드 시스템은 비대칭 암호화를 사용하여 대칭 세션 키를 협상한 다음, 대량의 트래픽은 대칭적으로 암호화합니다.

해싱(Hashing)(SHA-256, SHA-3)은 고정 길이의 다이제스트를 생성하는 단방향 함수입니다. 해시는 암호화가 아닙니다. 키가 없기 때문에 키로 역변환할 수 없습니다. 솔트(salt)를 사용한 비밀번호 해시(bcrypt, scrypt, Argon2 또는 PBKDF2 사용)는 사용자별 임의 값을 추가하여 레인보우 테이블 공격을 무력화합니다. 해시는 무결성 검증을 제공하며, HMAC은 해시와 비밀 키를 결합하여 무결성과 인증을 모두 제공합니다.

**암호 모드(Cipher modes)**는 알고리즘만큼이나 중요합니다. ECB 모드의 AES는 각 블록을 독립적으로 암호화하여 동일한 평문 블록에 대해 동일한 암호문을 생성합니다. 이는 데이터 패턴을 유출하는 치명적인 속성입니다. AES-GCM(Galois/Counter Mode)은 한 번의 처리로 기밀성과 무결성을 모두 제공하며 최신 프로토콜의 표준입니다. 적절한 패딩과 HMAC을 사용하는 CBC 모드도 허용되지만 올바르게 구현하기가 더 복잡합니다.

키 관리 및 스토리지

암호화의 강도는 키 관리에 달려 있습니다. 키는 강력한 엔트로피로 생성되어야 하고, 보호하는 데이터와 별도로 저장되어야 하며, 정해진 주기에 따라 교체되고, 폐기 시 파기되어야 합니다. **하드웨어 보안 모듈(Hardware Security Modules, HSM)**은 변조 방지 키 스토리지와 암호화 가속 기능을 제공합니다. **신뢰 플랫폼 모듈(Trusted Platform Module, TPM)**은 엔드포인트에 있는 칩으로, BitLocker 및 측정된 부팅(measured boot)에서 사용하는 키를 저장합니다. **키 에스크로(Key escrow)**는 합법적인 복구를 위해 신뢰할 수 있는 제3자에게 키 사본을 보관하는 것이고, **키 복구 에이전트(key recovery agents)**는 기업이 필요할 때 직원 데이터를 복호화할 수 있도록 허용합니다. 클라우드 KMS 서비스(AWS KMS, Azure Key Vault, Google Cloud KMS)는 봉투 암호화(envelope encryption)를 제공합니다. 이는 데이터 암호화 키(DEK)가 데이터를 보호하고, 이 DEK 자체는 HSM에 보관된 키 암호화 키(KEK)에 의해 암호화되는 방식입니다.

공개 키 기반 구조

PKI는 **인증 기관(Certificate Authority, CA)**이 발급한 인증서를 통해 신원을 공개 키에 바인딩합니다. 하위 CA는 루트 CA에 체인으로 연결되며, 이 루트 CA의 인증서는 사전에 신뢰되어야 합니다. 인증서 수명 주기는 개인 키와 함께 생성된 **인증서 서명 요청(Certificate Signing Request, CSR)**으로 시작됩니다.

openssl req -new -newkey rsa:2048 -nodes \
  -keyout server.key -out server.csr \
  -subj "/CN=www.example.com/O=Example Corp/C=US"

CA는 요청자를 검증하고 CSR에 서명한 후 X.509 인증서를 발급합니다. 폐기 정보는 인증서 폐기 목록(Certificate Revocation Lists, CRLs)(주기적으로 다운로드되는 폐기된 일련번호 목록) 또는 온라인 인증서 상태 프로토콜(Online Certificate Status Protocol, OCSP) 응답기(개별 인증서에 대한 쿼리에 실시간으로 응답)를 통해 게시됩니다. **OCSP 스테이플링(OCSP stapling)**은 서버가 TLS 핸드셰이크 중에 최근의 서명된 상태 정보를 제시하여 클라이언트가 CA에 조회하는 것을 방지합니다. 인증서는 만료되며 갱신해야 합니다. ACME(Let’s Encrypt, 내부 ACME 서버)를 통한 자동화는 인증서 만료로 인한 서비스 중단을 방지합니다.

코드 서명 및 무결성 검증

코드 서명은 개발자의 개인 키를 사용하여 소프트웨어 아티팩트에 서명하는 방식입니다. 수신자는 개발자의 인증서로 서명을 검증하여 무결성과 출처를 모두 확인합니다. 이는 공급망(supply-chain) 변조를 방지합니다. 파일 무결성 모니터링 도구(Tripwire, AIDE)나 다운로드 파일과 함께 sha256sum 값을 게시하는 해시 공개 방식도 유사하게 무단 수정을 탐지합니다. 하지만 해싱만으로는 파일이 특정 값과 일치한다는 것만 증명할 뿐, 누가 그 값을 생성했는지는 인증하지 못합니다. PKI 기반의 디지털 서명만이 무결성과 부인 방지(non-repudiation)를 모두 제공합니다.

보존, 삭제 및 안전한 폐기

보존 정책은 각 데이터 클래스를 얼마나 오래 보관해야 하고 언제 삭제해야 하는지를 정의합니다. 규제에서는 종종 최소 보존 기간(예: 금융 기록 7년)과 최대 보존 기간(예: 개인 데이터는 필요 이상으로 보관하지 않음)을 모두 요구합니다. 백업도 예외는 아닙니다. 정보 주체가 삭제권(right to erasure)을 행사하면, 조직은 백업에서 해당 데이터를 제거하거나 기술적 제약을 문서화하고 보완 통제를 마련하는 등 방어 가능한 프로세스를 갖추어야 합니다. 법적 보존(Legal hold)은 일반적인 보존 정책에 우선하며, 소송 기간 동안 데이터를 동결시킵니다.

미디어의 수명이 다하면, 데이터의 민감도와 미디어의 처리 방식에 맞춰 데이터 삭제(sanitization)를 수행해야 합니다. NIST SP 800-88은 세 가지 수준을 정의합니다: Clear(논리적 덮어쓰기, 조직 내 재사용에 충분), Purge(암호화 삭제, 블록 삭제 또는 소자(degaussing), 외부 재사용에 충분), Destroy(파쇄, 분쇄, 소각, 분말화). 암호화 삭제(Cryptographic erasure)는 암호화 키를 파기하여 암호문을 복구 불가능하게 만드는 방식으로, 용도가 변경되는 자체 암호화 드라이브에 빠르고 효과적입니다. 소자(Degaussing)는 자기 미디어를 사용할 수 없게 만들며 SSD에는 효과가 없습니다. 물리적 파기는 손상된 미디어나 가장 높은 등급의 데이터를 처리하는 유일하게 확실한 방법입니다.

실제 시나리오: 키 관리 실패로 인한 침해 사고

한 SaaS 회사가 AES-256을 사용하여 고객 데이터베이스를 암호화했지만, 암호화 키를 애플리케이션 코드와 동일한 리포지토리의 평문 구성 파일에 저장했습니다. 한 개발자가 실수로 리포지토리를 공개 GitHub 계정에 푸시하자, 자동화된 자격 증명 스캐닝 봇이 11분 만에 키를 발견했습니다. 공격자는 이 키를 사용하여 공개적으로 액세스 가능한 S3 버킷에 저장되어 있던(별개의 잘못된 구성) 데이터베이스 백업을 복호화했습니다. 기술적으로 암호화 자체는 올바르게 수행되었지만(AES-256은 무차별 대입 공격으로 깰 수 없음), 키 관리에 치명적인 결함이 있었습니다. 올바른 키 관리 방식은 소스 코드나 구성 파일이 아닌, IAM 역할을 통해 액세스가 제어되는 보안 암호 관리자(AWS Secrets Manager, HashiCorp Vault)에 키를 저장하는 것입니다.

← 클라우드 · 모든 도메인 · 비즈니스 연속성 및 재해 복구 →

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