Microsoft SDL 암호화 권장 사항

소개

이 문서에는 Microsoft 플랫폼에서 암호화를 사용하는 방법에 대한 권장 사항과 모범 사례가 포함되어 있습니다. 여기에 나와 있는 대부분의 콘텐츠는 보안 개발 수명 주기를 만드는 데 사용된 Microsoft의 자체 내부 보안 표준을 다른 표현으로 해석하거나 취합한 것입니다. Microsoft에서 자체 제품 및 서비스에 요구하는 것과 동일한 API, 알고리즘, 프로토콜 및 키 길이를 사용하도록 제품을 디자인할 때 참조로 사용됩니다.

Windows가 아닌 플랫폼의 개발자도 이러한 권장 사항을 활용할 수 있습니다. API 및 라이브러리 이름이 다를 수 있지만, 알고리즘 선택, 키 길이 및 데이터 보호와 관련된 모범 사례는 플랫폼 간에 비슷합니다.

보안 프로토콜, 알고리즘 및 키 길이 권장 사항

SSL/TLS 버전

제품 및 서비스에서 사용해야 하는 암호화된 보안 버전의 SSL/TLS는 다음과 같습니다.

  • TLS 1.2를 사용하도록 설정해야 합니다.

  • TLS 1.1 및 TLS 1.0은 이전 버전과의 호환성을 위해서만 사용하도록 설정해야 합니다.

  • SSL 3 및 SSL 2는 기본적으로 사용하지 않도록 설정해야 합니다.

대칭 블록 암호, 암호화 모드 및 초기화 벡터

블록 암호

대칭 블록 암호화를 사용하는 제품의 경우:

  • 새 코드에는 AES(Advanced Encryption Standard)가 권장됩니다.

  • 기존 코드에는 이전 버전과의 호환성을 위해 3DES(3키 3중 Data Encryption Standard)가 허용됩니다.

  • RC2, DES, 2키 3DES, DESX 및 Skipjack을 포함한 다른 모든 블록 암호는 이전 데이터를 해독하는 데만 사용해야 하며, 암호화에 사용하는 경우 바꿔야 합니다.

대칭 블록 암호화 알고리즘의 경우 128비트의 최소 키 길이가 권장됩니다. 새 코드에 권장되는 유일한 블록 암호화 알고리즘은 AES입니다(AES-128, AES-192 및 AES-256은 모두 허용되며, AES-192는 일부 프로세서에서 최적화하는 데 충분하지 않음). 현재 3키 3DES는 기존 코드에서 이미 사용 중인 경우 허용되지만, AES로 전환하는 것이 좋습니다. DES, DESX, RC2 및 Skipjack은 더 이상 안전한 것으로 간주되지 않습니다. 이러한 알고리즘은 이전 버전과의 호환성을 위해 기존 데이터의 암호를 해독하는 데만 사용해야 하며, 권장되는 블록 암호를 사용하여 데이터를 다시 암호화해야 합니다.

암호화 모드

대칭 알고리즘은 다양한 모드에서 작동할 수 있으며, 대부분은 연속된 일반 텍스트 및 암호 텍스트 블록에 대한 암호화 작업을 함께 연결합니다.

대칭 블록 암호는 다음 암호화 모드 중 하나에서 사용해야 합니다.

  • CBC(암호화 블록 체인)

  • CTS(암호 텍스트 가로채기)

  • XTS(암호 텍스트 가로채기를 사용하는 XEX 기반 Tweaked-Codebook)

아래에 포함된 모드와 같은 일부 다른 암호화 모드에는 잘못 사용될 가능성이 더 높은 구현 문제가 있습니다. 특히 ECB(Electronic Code Book) 작동 모드는 피해야 합니다. "스트리밍 암호화 모드"(예: CTR)에서 블록 암호를 사용하여 동일한 IV(초기화 벡터)를 다시 사용하면 암호화된 데이터가 공개될 수 있습니다. 아래 모드 중 하나를 사용하는 경우 보안을 추가로 검토하는 것이 좋습니다.

  • OFB(출력 피드백)

  • CFB(암호화 피드백)

  • CTR(카운터)

  • CCM(CBC-MAC를 사용하는 카운터)

  • GCM(Galois/카운터 모드)

  • 위의 "권장" 목록에 없는 다른 모드

IV(초기화 벡터)

모든 대칭 블록 암호도 초기화 벡터로 암호화된 강한 난수와 함께 사용해야 합니다. 초기화 벡터는 상수 값이 아니어야 합니다. 암호화된 강한 난수를 생성하는 방법에 대한 권장 사항은 난수 생성기를 참조하세요.

특히 OFB(출력 피드백) 또는 CTR(카운터)과 같은 스트리밍 암호화 모드를 사용할 때 암호화되는 데이터에 대한 정보를 공개할 수 있으므로 여러 암호화 작업을 수행하는 경우 초기화 벡터를 다시 사용하면 안 됩니다.

비대칭 알고리즘, 키 길이 및 패딩 모드

RSA

  • RSA는 암호화, 키 교환 및 서명에 사용해야 합니다.

  • RSA 암호화는 OAEP 또는 RSA-PSS 패딩 모드를 사용해야 합니다. 기존 코드는 호환성을 위해서만 PKCS #1 v1.5 패딩 모드를 사용해야 합니다.

  • Null 패딩은 사용하지 않는 것이 좋습니다.

  • 키 >= 2048비트를 사용하는 것이 좋습니다.

ECDSA

  • >= 256비트 키가 있는 ECDSA를 사용하는 것이 좋습니다.

  • ECDSA 기반 서명은 NIST에서 승인한 세 가지 곡선(P-256, P-384 또는 P521) 중 하나를 사용해야 합니다.

ECDH

  • >= 256비트 키가 있는 ECDH를 사용하는 것이 좋습니다.

  • ECDH 기반 키 교환은 NIST에서 승인한 세 가지 곡선(P-256, P-384 또는 P521) 중 하나를 사용해야 합니다.

정수 Diffie-Hellman

  • 키 길이 >= 2048비트를 사용하는 것이 좋습니다.

  • 그룹 매개 변수는 잘 알려진 명명된 그룹(예: RFC 7919)이거나 신뢰할 수 있는 당사자가 생성하고 사용하기 전에 인증해야 합니다.

키 수명

  • 모든 비대칭 키의 수명은 최대 5년이어야 하고, 권장 수명은 1년입니다.

  • 모든 대칭 키의 수명은 최대 3년이어야 하고, 권장 수명은 1년입니다.

  • 제한된 활성 수명을 얻기 위해 키를 바꾸는 메커니즘을 제공하거나 프로세스가 있어야 합니다. 활성 수명이 종료되면 키는 새 데이터(예: 암호화 또는 서명용)를 생성하는 데 사용하지 않아야 하지만, 데이터(예: 암호 해독 또는 확인용)를 읽는 데는 계속 사용할 수 있습니다.

난수 생성기

임의성이 필요한 경우 모든 제품 및 서비스는 암호화된 보안 난수 생성기를 사용해야 합니다.

CNG

  • BCRYPT_USE_SYSTEM_PREFERRED_RNG 플래그와 함께 BCryptGenRandom 사용

CAPI

Win32/64

  • 레거시 코드는 커널 모드에서 RtlGenRandom을 사용할 수 있습니다.

  • 새 코드는 BCryptGenRandom 또는 CryptGenRandom을 사용해야 합니다.

  • C 함수 Rand_s()도 권장됩니다(Windows에서는 CryptGenRandom을 호출).

  • Rand_s()는 Rand()를 안전하고 성능이 좋은 대체품입니다. Rand()는 암호화 애플리케이션에 사용할 수 없으며, 내부 테스트용으로만 사용할 수 있습니다.

  • SystemPrng 함수는 커널 모드 코드에 사용하는 것이 좋습니다.

.NET

Windows 스토어 앱

권장하지 않음

  • 난수 생성과 관련된 안전하지 않은 함수에는 rand,System.Random(.NET), GetTickCountGetTickCount64가 포함됩니다.

  • 이중 타원 곡선 난수 생성기("DUAL_EC_DRBG") 알고리즘을 사용하지 않는 것이 좋습니다.

Windows 플랫폼에서 지원하는 암호화 라이브러리

Windows 플랫폼에서 Microsoft는 운영 체제에 기본 제공되는 암호화 API를 사용하도록 권장합니다. 다른 플랫폼에서는 개발자가 사용할 비 플랫폼 암호화 라이브러리를 평가하도록 선택할 수 있습니다. 일반적으로 플랫폼 암호화 라이브러리는 애플리케이션과 함께 번들로 제공되는 것이 아니라 운영 체제의 일부로 제공되므로 더 자주 업데이트됩니다.

플랫폼 및 비 플랫폼 암호화와 관련된 모든 사용은 다음 요구 사항에 따라 결정해야 합니다.

  1. 라이브러리는 알려진 보안 취약성이 없는 최신 지원 버전이어야 합니다.

  2. 최신 보안 프로토콜, 알고리즘 및 키 길이를 지원해야 합니다.

  3. (선택 사항) 라이브러리는 이전 버전과의 호환성을 위해서만 이전 보안 프로토콜/알고리즘을 지원할 수 있어야 합니다.

네이티브 코드

  • 암호화 기본 형식: 릴리스가 Windows 또는 Windows Phone에 있는 경우 가능하면 CNG를 사용합니다. 그렇지 않은 경우 CryptoAPI(Windows Vista 이후의 Windows에서 레거시 구성 요소로 지원되는 CAPI라고도 함)를 사용합니다.

  • SSL/TLS/DTLS: WinINet,WinHTTP,Schannel,IXMLHTTPRequest2 또는 IXMLHTTPRequest3.

    • TLS 1.2를 지원하려면 WinHttpSetOption을 사용하여 WinHTTP 앱을 빌드해야 합니다.
  • 코드 서명 확인: WinVerifyTrust는 Windows 플랫폼에서 코드 서명을 확인하는 데 지원되는 API입니다.

  • 인증서 유효성 검사(코드 서명 또는 SSL/TLS/DTLS에 대한 제한된 인증서 유효성 검사에 사용됨): CAPI2 API(예: CertGetCertificateChainCertVerifyCertificateChainPolicy)

관리 코드

  • 암호화 기본 형식: System.Security.Cryptography 네임스페이스에 정의된 API를 사용합니다. CNG 클래스가 우선 적용됩니다.

  • 사용 가능한 최신 버전의 .Net Framework를 사용합니다. .Net Framework 버전 4.6 이상이어야 합니다. 이전 버전이 필요한 경우 " SchUseStrongCrypto " 레지스트리 키가 TLS 1.2를 해당 애플리케이션에 사용하도록 설정되어 있는지 확인합니다.

  • 인증서 유효성 검사: System.Security.Cryptography.X509Certificates 네임스페이스에 정의된 API를 사용합니다.

  • SSL/TLS/DTLS: System.Net 네임스페이스에 정의된 API(예: HttpWebRequest)를 사용합니다.

키 파생 함수

키 파생은 공유 비밀 또는 기존 암호화 키에서 암호화 키 자료를 파생하는 프로세스입니다. 제품에서는 권장되는 키 파생 함수를 사용해야 합니다. 사용자가 선택한 암호에서 키를 파생하거나 인증 시스템의 스토리지에 대한 암호를 해시하는 것은 이 지침에서 설명하지 않는 특별한 경우이며, 개발자는 전문가와 상담해야 합니다.

다음 표준은 사용하도록 권장되는 KDF 함수를 지정합니다.

  • NIST SP 800-108: 의사 난수 함수를 사용하여 키를 파생하는 방법에 대한 권장 사항. 특히 카운터 모드의 KDF이며, HMAC를 의사 난수 함수로 사용합니다.

  • NIST SP 800-56A(수정 버전 2): 불연속 로그 암호화를 사용하는 Pair-Wise 키 설정 체계에 대한 권장 사항. 특히 5.8.1 섹션의 "단일 단계 키 파생 함수"를 권장합니다.

기존 키에서 키를 파생하려면 다음 알고리즘 중 하나와 함께 BCryptKeyDerivation API를 사용합니다.

  • BCRYPT_SP800108_CTR_HMAC_ALGORITHM

  • BCRYPT_SP80056A_CONCAT_ALGORITHM

공유 비밀(키 계약의 출력)에서 키를 파생하려면 다음 알고리즘 중 하나와 함께 BCryptDeriveKey API를 사용합니다.

  • BCRYPT_KDF_SP80056A_CONCAT

  • BCRYPT_KDF_HMAC

인증서 유효성 검사

SSL, TLS 또는 DTLS를 사용하는 제품에서는 연결하는 엔터티의 X.509 인증서를 완전히 확인해야 합니다. 여기에는 다음에 대한 인증서 확인이 포함됩니다.

  • 도메인 이름

  • 유효 날짜(시작 날짜 및 만료 날짜 모두)

  • 해지 상태

  • 사용법(예: 서버의 경우 "서버 인증", 클라이언트의 경우 "클라이언트 인증")

  • 신뢰 체인 - 인증서는 플랫폼에서 신뢰할 수 있거나 관리자가 명시적으로 구성한 루트 인증 기관(CA)에 연결되어야 합니다.

이러한 확인 테스트 중 하나라도 실패하는 경우 제품에서 엔터티와의 연결을 종료해야 합니다.

"자체 서명된" 인증서를 신뢰하는 클라이언트(예: 기본 구성의 Exchange 서버에 연결하는 메일 클라이언트)는 인증서 확인 검사를 무시할 수 있습니다. 그러나 자체 서명된 인증서는 기본적으로 신뢰를 전달하거나, 해지를 지원하거나, 키 갱신을 지원하지 않습니다. 자체 서명된 인증서는 다른 신뢰할 수 있는 원본(예: 인증되고 무결성이 보호되는 전송을 통해 인증서를 제공하는 신뢰할 수 있는 엔터티)에서 가져온 경우에만 신뢰해야 합니다.

암호화 해시 함수

제품에서는 SHA-2 해시 알고리즘 제품군(SHA256, SHA384 및 SHA512)을 사용해야 합니다. 보안을 위해 암호화 해시를 128비트 미만으로 자르는 것은 권장되지 않습니다.

MAC/HMAC/키 해시 알고리즘

MAC는 받는 사람이 비밀 키를 사용하여 보낸 사람의 신뢰성과 메시지 무결성을 모두 확인할 수 있도록 메시지에 연결되는 정보입니다.

모든 기본 해시 또는 대칭 암호화 알고리즘도 사용하도록 권장되는 한 HMAC(해시 기반 MAC) 또는 블록 암호 기반 MAC를 사용하는 것이 좋습니다. 현재 여기에는 HMAC-SHA2 함수(HMAC-SHA256, HMAC-SHA384 및 HMAC-SHA512)가 포함됩니다.

HMAC를 128비트 미만으로 자르는 것은 권장되지 않습니다.

디자인 및 운영 고려 사항

  • 필요에 따라 암호화 키를 바꾸는 메커니즘을 제공해야 합니다. 키의 활성 수명이 만료되거나 암호화 키가 손상된 경우 키를 바꿔야 합니다. 인증서를 갱신할 때마다 새 키로 갱신해야 합니다.

  • 데이터를 보호하기 위해 암호화 알고리즘을 사용하는 제품에는 나중에 다른 알고리즘으로 마이그레이션할 수 있도록 지원하는 데 충분한 메타데이터가 해당 콘텐츠와 함께 포함되어야 합니다. 여기에는 사용되는 알고리즘, 키 크기, 초기화 벡터 및 패딩 모드가 포함됩니다.

  • 사용 가능한 경우 제품에서 다시 구현하는 대신 플랫폼에서 제공하는 입증된 암호화 프로토콜을 사용해야 합니다. 여기에는 서명 형식(예: 기존 표준 형식 사용)이 포함됩니다.

  • 대칭 스트림 암호화(예: RC4)는 사용하지 않아야 합니다. 대칭 스트림 암호화 대신 제품에서 키 길이가 128비트 이상인 AES와 같은 블록 암호화를 사용해야 합니다.

  • 최종 사용자에게 암호화 작업 오류를 보고하지 않습니다. 오류를 원격 호출자(예: 웹 클라이언트 또는 클라이언트-서버 시나리오의 클라이언트)에 반환하는 경우 일반 오류 메시지만 사용합니다.

    • 범위를 벗어남 또는 잘못된 길이 오류를 직접 보고하는 것과 같은 불필요한 정보를 제공하지 않습니다. 자세한 정보 로깅이 사용하도록 설정된 경우에만 서버에서만 자세한 오류를 기록합니다.
  • 다음을 통합하는 모든 디자인에서 보안을 추가로 검토하는 것이 좋습니다.

    • 주로 보안에 초점을 맞춘 새로운 프로토콜(인증 또는 권한 부여 프로토콜)

    • 암호화를 새롭거나 비표준 방식으로 사용하는 새로운 프로토콜. 고려 사항의 예는 다음과 같습니다.

      • 프로토콜을 구현하는 제품에서 프로토콜 구현의 일환으로 암호화 API 또는 메서드를 호출하나요?

      • 프로토콜이 인증 또는 권한 부여에 사용되는 다른 프로토콜에 종속되나요?

      • 프로토콜에서 키와 같은 암호화 요소에 대한 저장 형식을 정의하나요?

  • 자체 서명된 인증서는 프로덕션 환경에 권장되지 않습니다. 원시 암호화 키의 사용과 마찬가지로 자체 서명된 인증서를 사용하는 경우 기본적으로 사용자 또는 관리자에게 신뢰 결정에 대한 기준이 제공되지 않습니다.

    • 이와 대조적으로 신뢰할 수 있는 인증 기관을 기반으로 하는 인증서를 사용하는 경우 연결된 프라이빗 키 사용에 대한 기준이 명확해지고, 보안 오류 발생 시 해지 및 업데이트를 수행할 수 있습니다.

저장하기 전에 중요한 데이터 암호화

DPAPI/DPAPI-NG

시스템을 다시 부팅하는 동안 유지할 필요가 있는 데이터의 경우:

  • CryptProtectData

  • CryptUnprotectData

  • NCryptProtectSecret(Windows 8 CNG DPAPI)

시스템을 다시 부팅하는 동안 유지할 필요가 없는 데이터의 경우:

  • CryptProtectMemory

  • CryptUnprotectMemory

여러 도메인 계정 및 컴퓨터에서 유지하고 액세스할 필요가 있는 데이터의 경우:

SQL Server TDE

SQL Server TDE(투명한 데이터 암호화)를 사용하여 중요한 데이터를 보호할 수 있습니다.

SDL 암호화 알고리즘 및 키 강도 요구 사항을 충족하는 TDE DEK(데이터베이스 암호화 키)를 사용해야 합니다. 현재는 AES_128, AES_192 및 AES_256 권장됩니다. TRIPLE_DES_3KEY 권장되지 않습니다.

SQL TDE를 사용하는 경우 고려해야 할 몇 가지 중요 사항은 다음과 같습니다.

  • TDE가 사용하도록 설정된 경우에도 SQL Server는 FILESTREAM 데이터에 대한 암호화를 지원하지 않습니다.

  • TDE는 데이터베이스에서 들어오거나 나가는 데이터에 대해 자동으로 암호화를 제공하지 않습니다. 또한 SQL Server 데이터베이스에 대한 암호화된 연결을 사용하도록 설정해야 합니다. 암호화된 연결을 사용하도록 설정하는 방법에 대한 지침은 데이터베이스 엔진에 대한 암호화된 연결 사용(SQL Server 구성 관리자)을 참조하세요.

  • TDE로 보호되는 데이터베이스를 다른 SQL Server 인스턴스로 이동하는 경우 TDE DEK(데이터 암호화 키)를 보호하는 인증서도 이동하여 대상 SQL Server 인스턴스의 master 데이터베이스에 설치해야 합니다. 자세한 내용은 TechNet 문서를 참조하여 TDE보호된 데이터베이스를 다른 SQL Server로 이동하세요.

자격 증명 관리

Windows 자격 증명 관리자 API 또는 Microsoft Azure KeyVault를 사용하여 암호 및 자격 증명 데이터를 보호합니다.

Windows 스토어 앱

Windows.Security.CryptographyWindows.Security.Cryptography.DataProtection 네임스페이스의 클래스를 사용하여 비밀 및 중요한 데이터를 보호합니다.

  • ProtectAsync

  • ProtectStreamAsync

  • UnprotectAsync

  • UnprotectStreamAsync

Windows.Security.Credentials 네임스페이스의 클래스를 사용하여 암호 및 자격 증명 데이터를 보호합니다.

.NET

시스템을 다시 부팅하는 동안 유지할 필요가 있는 데이터의 경우:

  • ProtectedData.Protect

  • ProtectedData.Unprotect

시스템을 다시 부팅하는 동안 유지할 필요가 없는 데이터의 경우:

  • ProtectedMemory.Protect

  • ProtectedMemory.Unprotect

구성 파일의 경우

RSAProtectedConfigurationProvider 또는 DPAPIProtectedConfigurationProvider를 사용하여 각각 RSA 암호화 또는 DPAPI를 통해 구성을 보호합니다.

RSAProtectedConfigurationProvider는 클러스터의 여러 컴퓨터에서 사용할 수 있습니다. 자세한 내용은 보호된 구성을 사용하여 구성 정보 암호화를 참조하세요.