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차원 데이터 암호화 표준)는 이전 버전과의 호환성을 위해 기존 코드에서 허용됩니다.

  • RC2, DES, 2-Key 3DES, DESX 및 Skipjack을 비롯한 다른 모든 블록 암호화는 이전 데이터의 암호 해독에만 사용해야 하며 암호화에 사용되는 경우 교체해야 합니다.

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

암호 모드

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

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

아래에 포함된 암호화 모드와 같은 일부 다른 암호화 모드에는 잘못 사용될 가능성이 높아진 구현 문제가 있습니다. 특히 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) 중 하나를 사용해야 합니다.

정수 디피 헬만

  • 키 길이 >= 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

  • RNGCryptoServiceProvider 사용

Windows 스토어 앱

권장하지 않음

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

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

Windows 플랫폼 지원 암호화 라이브러리

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

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

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

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

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

네이티브 코드

관리 코드

키 파생 함수

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

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

  • NIST SP 800-108: 의사 함수를 사용하는 키 파생에 대한 권장 사항입니다. 특히 HMAC를 의사 정의 함수로 사용하는 카운터 모드의 KDF

  • NIST SP 800-56A(수정 버전 2): 불연속 로그 암호화를 사용하는 쌍별 키 설정 체계에 대한 권장 사항입니다. 특히 섹션 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 인증서를 완전히 확인해야 합니다. 여기에는 인증서 확인이 포함됩니다.'

  • Do기본 이름입니다.

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

  • 해지 상태

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

  • 신뢰 체인. 인증서는 플랫폼에서 신뢰하거나 관리자가 명시적으로 구성한 루트 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를 사용하는 경우 고려해야 할 몇 가지 중요 사항은 다음과 같습니다.

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

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

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

자격 증명 관리

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