다음을 통해 공유

보안 프레임: 암호화 | 완화

제품/서비스 조항
웹 응용 프로그램
데이터베이스
IoT 디바이스
IoT 클라우드 게이트웨이
Dynamics CRM 모바일 클라이언트
Dynamics CRM Outlook 클라이언트
ID 서버

승인된 대칭 블록 암호화 및 키 길이만 사용

제목 세부 정보
구성 요소 웹 애플리케이션
SDL 단계 빌드
적용 가능한 기술 일반
특성 해당 없음(N/A)
참조 해당 없음(N/A)
단계

제품은 조직의 Crypto Advisor에서 명시적으로 승인한 대칭 블록 암호화 및 관련 키 길이만 사용해야 합니다. Microsoft에서 승인된 대칭 알고리즘에는 다음 블록 암호화가 포함됩니다.

  • 새 코드 AES-128의 경우 AES-192 및 AES-256이 허용됩니다.
  • 기존 코드와의 이전 버전과의 호환성을 위해 3가지 키 3DES를 사용할 수 있습니다.
  • 대칭 블록 암호화를 사용하는 제품의 경우:
    • 새 코드에는 AES(Advanced Encryption Standard)가 필요합니다.
    • 3DES(3차원 데이터 암호화 표준)는 이전 버전과의 호환성을 위해 기존 코드에서 허용됩니다.
    • RC2, DES, 2 키 3DES, DESX 및 Skipjack을 비롯한 다른 모든 블록 암호는 이전 데이터의 암호 해독에만 사용할 수 있으며 암호화에 사용되는 경우 교체해야 합니다.
  • 대칭 블록 암호화 알고리즘의 경우 최소 키 길이는 128비트입니다. 새 코드에 권장되는 유일한 블록 암호화 알고리즘은 AES입니다(AES-128, AES-192 및 AES-256은 모두 허용됨).
  • 3 키 3DES는 기존 코드에서 이미 사용 중인 경우 현재 허용됩니다. AES로 전환하는 것이 좋습니다. DES, DESX, RC2 및 Skipjack은 더 이상 안전한 것으로 간주되지 않습니다. 이러한 알고리즘은 이전 버전과의 호환성을 위해 기존 데이터의 암호 해독에만 사용할 수 있으며 권장 블록 암호화를 사용하여 데이터를 다시 암호화해야 합니다.

모든 대칭 블록 암호화는 승인된 암호화 모드와 함께 사용해야 하며, 적절한 IV(초기화 벡터)를 사용해야 합니다. 적절한 IV는 일반적으로 난수이며 절대로 상수 값이어서는 안 됩니다.

레거시 또는 승인되지 않은 암호화 알고리즘의 사용과 기존 데이터를 읽기 위한 더 작은 키 길이(새 데이터 작성과 반대)는 조직의 Crypto Board 검토 후에 허용될 수 있습니다. 그러나 이 요구 사항에 대해 예외를 제출해야 합니다. 엔터프라이즈 배포의 경우, 제품은 약한 암호화를 사용해 데이터를 읽을 경우 관리자에게 경고하는 기능을 제공해야 합니다. 이러한 경고는 설명이 가능하고 실행 가능해야 합니다. 경우에 따라 그룹 정책이 약한 암호화 사용을 제어하도록 하는 것이 적절할 수 있습니다.

관리형 암호화 민첩성에 허용되는 .NET 알고리즘(기본 설정 순서)

  • AesCng(FIPS 규격)
  • AuthenticatedAesCng(FIPS 규격)
  • AESCryptoServiceProvider(FIPS 규격)
  • AESManaged (비 FIPS 준수)

이 알고리즘은 machine.config 파일을 변경하지 않으면 SymmetricAlgorithm.Create 또는 CryptoConfig.CreateFromName 메서드를 통해 지정할 수 없습니다. 또한 .NET 3.5 이전 버전의 .NET에서 AES는 RijndaelManaged로 이름이 붙여진 상태이며, AesCng 및 AuthenticatedAesCng는 CodePlex를 통해 사용할 수 있으며, 기본 OS에서 CNG가 필요합니다.

대칭 암호에 승인된 블록 암호화 모드 및 초기화 벡터 사용

제목 세부 정보
구성 요소 웹 애플리케이션
SDL 단계 빌드
적용 가능한 기술 일반
특성 해당 없음(N/A)
참조 해당 없음(N/A)
단계 모든 대칭 블록 암호는 승인된 대칭 암호 모드와 함께 사용해야 합니다. 유일하게 승인된 모드는 CBC 및 CTS입니다. 특히 ECB(전자 코드 북) 작업 모드는 피해야 합니다. ECB를 사용하려면 조직의 Crypto Board를 검토해야 합니다. OFB, CFB, CTR, CCM 및 GCM 또는 기타 암호화 모드의 모든 사용은 조직의 Crypto Board에서 검토해야 합니다. CTR과 같은 "스트리밍 암호 모드"에서 블록 암호화와 동일한 IV(초기화 벡터)를 다시 사용하면 암호화된 데이터가 표시될 수 있습니다. 모든 대칭 블록 암호화는 적절한 IV(초기화 벡터)와 함께 사용해야 합니다. 적절한 IV는 암호화된 강력한 난수이며, 절대로 상수 값이 아닙니다.

승인된 비대칭 알고리즘, 키 길이 및 패딩 사용

제목 세부 정보
구성 요소 웹 애플리케이션
SDL 단계 빌드
적용 가능한 기술 일반
특성 해당 없음(N/A)
참조 해당 없음(N/A)
단계

금지된 암호화 알고리즘을 사용하면 제품 보안에 상당한 위험이 발생하며 피해야 합니다. 제품은 조직의 Crypto Board에서 명시적으로 승인한 암호화 알고리즘 및 관련 키 길이 및 패딩만 사용해야 합니다.

  • RSA- 암호화, 키 교환 및 서명에 사용할 수 있습니다. RSA 암호화는 OAEP 또는 RSA-KEM 패딩 모드만 사용해야 합니다. 기존 코드는 호환성을 위해서만 PKCS #1 v1.5 패딩 모드를 사용할 수 있습니다. null 패딩의 사용은 명시적으로 금지됩니다. 키 >= 새 코드에는 2048비트가 필요합니다. 현재의 코드는 조직의 암호화 위원회에서 검토한 후, 이전 버전과의 호환성을 위해서만 키 < 2048비트를 지원할 수 있습니다. 키 < 1024 비트는 이전 데이터의 암호 해독/확인에만 사용할 수 있으며 암호화 또는 서명 작업에 사용되는 경우 교체해야 합니다.
  • ECDSA- 서명에만 사용할 수 있습니다. 새 코드에는 =256비트 키가 있는 ECDSA >가 필요합니다. ECDSA 기반 서명은 세 가지 NIST 승인 곡선(P-256, P-384 또는 P521) 중 하나를 사용해야 합니다. 철저하게 분석된 곡선은 조직의 Crypto Board를 검토한 후에만 사용할 수 있습니다.
  • ECDH- 키 교환에만 사용할 수 있습니다. 새 코드에는 =256비트 키가 있는 ECDH >가 필요합니다. ECDH 기반 키 교환은 세 가지 NIST 승인 곡선(P-256, P-384 또는 P521) 중 하나를 사용해야 합니다. 철저하게 분석된 곡선은 조직의 Crypto Board를 검토한 후에만 사용할 수 있습니다.
  • DSA- 는 조직의 Crypto Board의 검토 및 승인 후에 허용될 수 있습니다. 보안 관리자에게 문의하여 조직의 Crypto Board 검토를 예약합니다. DSA 사용이 승인된 경우 2048비트 미만의 키 사용을 금지해야 합니다. CNG는 Windows 8 기준으로 2048비트 및 더 큰 키 길이를 지원합니다.
  • Diffie-Hellman- 은 세션 키 관리에만 사용할 수 있습니다. 키 길이 >= 새 코드에는 2048비트가 필요합니다. 기존 코드는 조직의 Crypto Board에서 검토한 후에 이전 버전과의 호환성을 위해서만 키 길이 < 2048비트를 지원할 수 있습니다. 키 < 1024비트가 사용되지 않을 수 있습니다.

    승인된 난수 생성기 사용

    제목 세부 정보
    구성 요소 웹 애플리케이션
    SDL 단계 빌드
    적용 가능한 기술 일반
    특성 해당 없음(N/A)
    참조 해당 없음(N/A)
    단계

    제품에서는 승인된 난수 발생기를 사용해야 합니다. 따라서 C 런타임 함수 rand, .NET Framework 클래스 System.Random 또는 GetTickCount와 같은 시스템 함수와 같은 의사 난수 함수는 이러한 코드에서 사용되지 않아야 합니다. 이중 타원 곡선 난수 생성기(DUAL_EC_DRBG) 알고리즘의 사용은 금지됩니다.

    • CNG- BCryptGenRandom(BCRYPT_USE_SYSTEM_PREFERRED_RNG 플래그의 사용이 권장됩니다. 단, 호출자가 0보다 큰 IRQL에서 실행될 수 있는 경우는 제외합니다[즉, PASSIVE_LEVEL])
    • CAPI- cryptGenRandom
    • Win32/64- RtlGenRandom(새 구현은 BCryptGenRandom 또는 CryptGenRandom을 사용해야 함) * rand_s * SystemPrng(커널 모드의 경우)
    • . . NET- RNGCryptoServiceProvider 또는 RNGCng
    • Windows 스토어 앱- Windows.Security.Cryptography.CryptographicBuffer.GenerateRandom 또는 .GenerateRandomNumber
    • Apple OS X (10.7+)/iOS (2.0 이상)- int SecRandomCopyBytes(SecRandomRef random, size_t count, uint8_t *bytes)
    • Apple OS X(<10.7)- /dev/random를 사용하여 난수 검색
    • Java(Google Android Java 코드 포함) - java.security.SecureRandom 클래스입니다. Android 4.3(Jelly Bean)의 경우 개발자는 Android 권장 해결 방법을 따르고 애플리케이션을 업데이트하여 /dev/urandom 또는 /dev/random의 엔트로피로 PRNG를 명시적으로 초기화해야 합니다.

    대칭 스트림 암호화 사용 안 함

    제목 세부 정보
    구성 요소 웹 애플리케이션
    SDL 단계 빌드
    적용 가능한 기술 일반
    특성 해당 없음(N/A)
    참조 해당 없음(N/A)
    단계 RC4와 같은 대칭 스트림 암호화를 사용하면 안 됩니다. 제품은 대칭 스트림 암호화 대신 블록 암호화, 특히 키 길이가 128비트 이상인 AES를 사용해야 합니다.

    승인된 MAC/HMAC/키 해시 알고리즘 사용

    제목 세부 정보
    구성 요소 웹 애플리케이션
    SDL 단계 빌드
    적용 가능한 기술 일반
    특성 해당 없음(N/A)
    참조 해당 없음(N/A)
    단계

    제품은 승인된 MAC(메시지 인증 코드) 또는 HMAC(해시 기반 메시지 인증 코드) 알고리즘만 사용해야 합니다.

    MAC(메시지 인증 코드)는 받는 사람이 비밀 키를 사용하여 보낸 사람의 신뢰성과 메시지의 무결성을 모두 확인할 수 있도록 하는 메시지에 첨부된 정보입니다. 모든 기본 해시 또는 대칭 암호화 알고리즘도 사용하도록 승인되는 한 해시 기반 MAC(HMAC) 또는 블록 암호화 기반 MAC 의 사용은 허용됩니다. 현재 여기에는 HMAC-SHA2 함수(HMAC-SHA256, HMAC-SHA384 및 HMAC-SHA512) 및 CMAC/OMAC1 및 OMAC2 블록 암호화 기반 MAC(AES 기반)가 포함됩니다.

    플랫폼 호환성을 위해 HMAC-SHA1 사용할 수 있지만 이 절차에 예외를 제출하고 조직의 Crypto 검토를 받아야 합니다. HMAC를 128비트 미만으로 잘림할 수 없습니다. 고객 방법을 사용하여 키를 해시하고 데이터를 해시하는 것은 승인되지 않았으며 사용하기 전에 조직의 Crypto Board 검토를 거쳐야 합니다.

    승인된 암호화 해시 함수만 사용

    제목 세부 정보
    구성 요소 웹 애플리케이션
    SDL 단계 빌드
    적용 가능한 기술 일반
    특성 해당 없음(N/A)
    참조 해당 없음(N/A)
    단계

    제품은 SHA-2 해시 알고리즘 제품군(SHA256, SHA384 및 SHA512)을 사용해야 합니다. 더 짧은 MD5 해시를 염두에 두고 디자인된 데이터 구조에 맞추기 위해 128비트 출력 길이와 같이 더 짧은 해시가 필요한 경우 제품 팀은 SHA2 해시(일반적으로 SHA256) 중 하나를 잘릴 수 있습니다. SHA384는 잘린 SHA512 버전입니다. 보안을 위해 128비트 미만으로 암호화 해시를 잘리는 것은 허용되지 않습니다. 새 코드는 MD2, MD4, MD5, SHA-0, SHA-1 또는 RIPEMD 해시 알고리즘을 사용하지 않아야 합니다. 해시 충돌은 이러한 알고리즘에 대해 계산 가능한 것으로, 이를 효과적으로 중단합니다.

    관리형 암호화 민첩성에 허용되는 .NET 해시 알고리즘(기본 설정 순서):

    • SHA512Cng (FIPS 준수)
    • SHA384Cng(FIPS 규격)
    • SHA256Cng(FIPS 규격)
    • SHA512Managed(비 FIPS 규격)(HashAlgorithm.Create 또는 CryptoConfig.CreateFromName 호출에서 알고리즘 이름으로 SHA512 사용)
    • SHA384Managed(비 FIPS 규격)(HashAlgorithm.Create 또는 CryptoConfig.CreateFromName 호출에서 SHA384를 알고리즘 이름으로 사용)
    • SHA256Managed(비 FIPS 규격)(HashAlgorithm.Create 또는 CryptoConfig.CreateFromName 호출에서 SHA256을 알고리즘 이름으로 사용)
    • SHA512CryptoServiceProvider(FIPS 규격)
    • SHA256CryptoServiceProvider(FIPS 규격)
    • SHA384CryptoServiceProvider(FIPS 규격)

    강력한 암호화 알고리즘을 사용하여 데이터베이스의 데이터 암호화

    제목 세부 정보
    구성 요소 데이터베이스
    SDL 단계 빌드
    적용 가능한 기술 일반
    특성 해당 없음(N/A)
    참조 암호화 알고리즘 선택
    단계 암호화 알고리즘은 권한이 없는 사용자가 쉽게 되돌릴 수 없는 데이터 변환을 정의합니다. SQL Server를 사용하면 관리자와 개발자가 DES, Triple DES, TRIPLE_DES_3KEY, RC2, RC4, 128비트 RC4, DESX, 128비트 AES, 192비트 AES 및 256비트 AES를 비롯한 여러 알고리즘 중에서 선택할 수 있습니다.

    SSIS 패키지는 암호화되고 디지털 서명되어야 합니다.

    제목 세부 정보
    구성 요소 데이터베이스
    SDL 단계 빌드
    적용 가능한 기술 일반
    특성 해당 없음(N/A)
    참조 디지털 서명을 사용하여 패키지의 출처를 식별, 위협 및 취약점 완화 (통합 서비스)
    단계 패키지의 원본은 패키지를 만든 개인 또는 조직입니다. 알 수 없거나 신뢰할 수 없는 원본에서 패키지를 실행하는 것은 위험할 수 있습니다. SSIS 패키지의 무단 변조를 방지하려면 디지털 서명을 사용해야 합니다. 또한 스토리지/전송 중 패키지의 기밀성을 보장하려면 SSIS 패키지를 암호화해야 합니다.

    중요한 데이터베이스 보안 개체에 디지털 서명 추가

    제목 세부 정보
    구성 요소 데이터베이스
    SDL 단계 빌드
    적용 가능한 기술 일반
    특성 해당 없음(N/A)
    참조 서명 추가(Transact-SQL)
    단계 중요한 데이터베이스 보안 개체의 무결성을 확인해야 하는 경우 디지털 서명을 사용해야 합니다. 저장 프로시저, 함수, 어셈블리 또는 트리거와 같은 데이터베이스 보안 개체는 디지털 서명할 수 있습니다. 다음은 이것이 유용할 수 있는 경우의 예입니다. ISV(독립 소프트웨어 공급업체)가 고객 중 한 명에게 제공되는 소프트웨어에 대한 지원을 제공했다고 가정해 보겠습니다. 지원을 제공하기 전에 ISV는 소프트웨어의 데이터베이스 보안 개체가 실수로 또는 악의적인 시도로 변조되지 않도록 하려고 합니다. 보안 개체가 디지털 서명된 경우 ISV는 디지털 서명을 확인하고 무결성의 유효성을 검사할 수 있습니다.

    SQL Server EKM을 사용하여 암호화 키 보호

    제목 세부 정보
    구성 요소 데이터베이스
    SDL 단계 빌드
    적용 가능한 기술 일반
    특성 해당 없음(N/A)
    참조 SQL Server EKM(확장 가능 키 관리),Azure Key Vault를 사용한 확장 가능 키 관리(SQL Server)
    단계 SQL Server 확장 가능 키 관리를 사용하면 데이터베이스 파일을 보호하는 암호화 키를 스마트 카드, USB 디바이스 또는 EKM/HSM 모듈과 같은 오프박스 디바이스에 저장할 수 있습니다. 또한 데이터베이스 관리자(sysadmin 그룹의 멤버 제외)로부터 데이터를 보호합니다. 데이터베이스 사용자만 외부 EKM/HSM 모듈에 액세스할 수 있는 암호화 키를 사용하여 데이터를 암호화할 수 있습니다.

    암호화 키를 데이터베이스 엔진에 표시하지 않아야 하는 경우 AlwaysEncrypted 기능 사용

    제목 세부 정보
    구성 요소 데이터베이스
    SDL 단계 빌드
    적용 가능한 기술 SQL Azure, 온-프레미스
    특성 SQL 버전 - V12, MsSQL2016
    참조 Always Encrypted(데이터베이스 엔진)
    단계 Always Encrypted는 Azure SQL Database 또는 SQL Server 데이터베이스에 저장된 신용 카드 번호 또는 국가/지역 식별 번호(예: 미국 사회 보장 번호)와 같은 중요한 데이터를 보호하도록 설계된 기능입니다. Always Encrypted를 사용하면 클라이언트가 클라이언트 애플리케이션 내에서 중요한 데이터를 암호화하고 데이터베이스 엔진(SQL Database 또는 SQL Server)에 암호화 키를 표시하지 않을 수 있습니다. 따라서 Always Encrypted는 데이터를 소유하고 볼 수 있는 사용자와 데이터를 관리하는 사용자(액세스 권한이 없음) 간에 구분을 제공합니다.

    IoT 디바이스에서 암호화 키를 안전하게 저장

    제목 세부 정보
    구성 요소 IoT 디바이스
    SDL 단계 빌드
    적용 가능한 기술 일반
    특성 디바이스 OS - Windows IoT Core, 디바이스 연결 - Azure IoT 디바이스 SDK
    참조 Windows IoT Core의 TPM, Windows IoT Core에서 TPM 설정, Azure IoT 디바이스 SDK에서 TPM 설정
    단계 대칭 키 또는 인증서 프라이빗 키를 안전하게 저장하기 위해 하드웨어 보호 스토리지, 예를 들어 TPM 또는 스마트 카드 칩을 사용합니다. Windows 10 IoT Core는 TPM 사용을 지원하며, 몇 가지 호환 가능한 TPM을 사용할 수 있습니다: 불연속 TPM(dTPM). 펌웨어 또는 디스크리트 TPM을 사용하는 것이 좋습니다. 소프트웨어 TPM은 개발 및 테스트 목적으로만 사용해야 합니다. TPM을 사용할 수 있고 키가 프로비전되면 토큰을 생성하는 코드는 중요한 정보를 하드 코딩하지 않고 작성해야 합니다.

    예시

    TpmDevice myDevice = new TpmDevice(0);
// Use logical device 0 on the TPM 
string hubUri = myDevice.GetHostName(); 
string deviceId = myDevice.GetDeviceId(); 
string sasToken = myDevice.GetSASToken(); 

var deviceClient = DeviceClient.Create( hubUri, AuthenticationMethodFactory. CreateAuthenticationWithToken(deviceId, sasToken), TransportType.Amqp);

    볼 수 있듯이 디바이스 기본 키는 코드에 없습니다. 대신 슬롯 0의 TPM에 저장됩니다. TPM 디바이스는 IoT Hub에 연결하는 데 사용되는 수명이 짧은 SAS 토큰을 생성합니다.

    IoT Hub에 대한 인증에 충분한 길이의 임의 대칭 키 생성

    제목 세부 정보
    구성 요소 IoT 클라우드 게이트웨이
    SDL 단계 빌드
    적용 가능한 기술 일반
    특성 게이트웨이 선택 - Azure IoT Hub
    참조 해당 없음(N/A)
    단계 IoT Hub는 디바이스 ID 레지스트리를 포함하고 디바이스를 프로비전하는 동안 임의의 대칭 키를 자동으로 생성합니다. 인증에 사용되는 키를 생성하려면 Azure IoT Hub ID 레지스트리의 이 기능을 사용하는 것이 좋습니다. 또한 IoT Hub를 사용하면 디바이스를 만드는 동안 키를 지정할 수 있습니다. 디바이스 프로비전 중에 키가 IoT Hub 외부에서 생성되는 경우 임의의 대칭 키 또는 256비트 이상을 만드는 것이 좋습니다.

    PIN을 사용해야 하고 원격 초기화가 가능한 디바이스 관리 정책이 있는지 확인합니다.

    제목 세부 정보
    구성 요소 Dynamics CRM 모바일 클라이언트
    SDL 단계 배치
    적용 가능한 기술 일반
    특성 해당 없음(N/A)
    참조 해당 없음(N/A)
    단계 PIN을 사용해야 하고 원격 초기화가 가능한 디바이스 관리 정책이 있는지 확인합니다.

    PIN/암호/자동 잠금이 필요하고 모든 데이터(예: BitLocker)를 암호화하는 디바이스 관리 정책이 있는지 확인합니다.

    제목 세부 정보
    구성 요소 Dynamics CRM Outlook 클라이언트
    SDL 단계 빌드
    적용 가능한 기술 일반
    특성 해당 없음(N/A)
    참조 해당 없음(N/A)
    단계 PIN/암호/자동 잠금이 필요하고 모든 데이터(예: BitLocker)를 암호화하는 디바이스 관리 정책이 있는지 확인합니다.

    ID 서버를 사용할 때 서명 키가 롤오버되는지 확인합니다.

    제목 세부 정보
    구성 요소 ID 서버
    SDL 단계 배치
    적용 가능한 기술 일반
    특성 해당 없음(N/A)
    참조 해당 없음(N/A)
    단계 ID 서버를 사용할 때 서명 키가 롤오버되는지 확인합니다. 참조 섹션의 링크는 ID 서버를 사용하는 애플리케이션에 중단을 일으키지 않고 이를 계획하는 방법을 설명합니다.

    ID 서버에서 암호화된 강력한 클라이언트 ID, 클라이언트 암호가 사용되는지 확인합니다.

    제목 세부 정보
    구성 요소 ID 서버
    SDL 단계 빌드
    적용 가능한 기술 일반
    특성 해당 없음(N/A)
    참조 해당 없음(N/A)
    단계

    ID 서버에서 암호화된 강력한 클라이언트 ID, 클라이언트 암호가 사용되는지 확인합니다. 클라이언트 ID 및 비밀을 생성하는 동안 다음 지침을 사용해야 합니다.

    • 클라이언트 ID로 임의 GUID 생성
    • 비밀로 암호화된 임의 256비트 키 생성