제품에는 조직의 Crypto Advisor에서 명시적으로 승인한 대칭 블록 암호화 및 관련 키 길이만 사용해야 합니다. 승인된 Microsoft 대칭 알고리즘에는 다음과 같은 블록 암호화가 포함됩니다.
새로운 코드의 경우 AES-128, AES-192, AES-256이 허용됩니다.
기존 코드를 사용하는 이전 버전과의 호환성을 위해 3개 키를 사용하는 3DES가 허용됩니다.
대칭 블록 암호화를 사용하는 제품의 경우:
새로운 코드에는 AES(Advanced Encryption Standard)가 필요합니다.
이전 버전과의 호환성을 위해 기존 코드에 3DES(3키 3중 Data Encryption Standard)가 허용됩니다.
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 단계
빌드
적용 가능한 기술
일반
특성
해당 없음
참조
해당 없음
단계
모든 대칭 블록 암호화는 승인된 대칭 암호화 모드와 함께 사용해야 합니다. 유일하게 승인된 모드는 CBC 및 CTS입니다. 특히 ECB(Electronic Code Book) 작동 모드는 피해야 합니다. ECB를 사용하려면 조직의 Crypto Board에서 검토해야 합니다. OFB, CFB, CTR, CCM 및 GCM 또는 다른 암호화 모드의 모든 사용은 조직의 Crypto Board에서 검토해야 합니다. 동일한 IV(초기화 벡터)를 "스트리밍 암호화 모드"의 블록 암호화(예: CTR)로 다시 사용하면 암호화된 데이터가 노출될 수 있습니다. 또한 모든 대칭 블록 암호화도 적절한 IV와 함께 사용해야 합니다. 적절한 IV는 암호화된 강력한 난수이며, 절대로 상수 값이 아닙니다.
승인된 비대칭 알고리즘, 키 길이 및 패딩 사용
타이틀
세부 정보
구성 요소
웹 애플리케이션
SDL 단계
빌드
적용 가능한 기술
일반
특성
해당 없음
참조
해당 없음
단계
금지된 암호화 알고리즘의 사용은 제품 보안에 상당한 위험을 초래하므로 피해야 합니다. 제품에서는 조직의 Crypto Board에서 명시적으로 승인한 암호화 알고리즘, 관련 키 길이 및 패딩만 사용해야 합니다.
RSA - 암호화, 키 교환 및 서명에 사용할 수 있습니다. RSA 암호화는 OAEP 또는 RSA-KEM 패딩 모드만 사용해야 합니다. 기존 코드는 호환성을 위해서만 PKCS #1 v1.5 패딩 모드를 사용할 수 있습니다. 널 패딩 사용은 명시적으로 금지됩니다. 새 코드에는 >= 2048비트의 키가 필요합니다. 기존 코드는 조직의 Crypto Board에서 검토한 후 이전 버전과의 호환성을 위해서만 <2,048비트의 키를 지원할 수 있습니다. <1,024비트의 키는 이전 데이터의 암호 해독/확인에만 사용할 수 있으며, 암호화 또는 서명 작업에 사용되는 경우 교체해야 합니다.
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 사용이 승인되면 2,048비트 미만의 키 사용을 금지해야 합니다. CNG는 Windows 8부터 2,048비트 이상의 키 길이를 지원합니다.
Diffie-Hellman - 세션 키 관리에만 사용할 수 있습니다. 새 코드에는 >=2,048비트의 키 길이가 필요합니다. 기존 코드는 조직의 Crypto Board에서 검토한 후 이전 버전과의 호환성을 위해서만 <2,048비트의 키 길이를 지원할 수 있습니다. <1,024비트의 키는 사용할 수 없습니다.
승인된 난수 생성기 사용
타이틀
세부 정보
구성 요소
웹 애플리케이션
SDL 단계
빌드
적용 가능한 기술
일반
특성
해당 없음
참조
해당 없음
단계
제품에서는 승인된 난수 발생기를 사용해야 합니다. 따라서 의사 난수 함수(예: rand C 런타임 함수, System.Random .NET Framework 클래스 또는 GetTickCount 시스템 함수)는 이러한 코드에 절대로 사용할 수 없습니다. 이중 타원 곡선 난수 생성기(DUAL_EC_DRBG) 알고리즘의 사용은 금지됩니다.
CNG - BCryptGenRandom(호출자가 0보다 큰 IRQL[즉 PASSIVE_LEVEL]에서 실행되지 않는 한 BCRYPT_USE_SYSTEM_PREFERRED_RNG 플래그를 사용하는 것이 좋음)
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 단계
빌드
적용 가능한 기술
일반
특성
해당 없음
참조
해당 없음
단계
대칭 스트림 암호화(예: RC4)는 사용하지 않아야 합니다. 대칭 스트림 암호화 대신 제품에서 키 길이가 128비트 이상인 AES와 같은 블록 암호화를 사용해야 합니다.
승인된 MAC/HMAC/키 해시 알고리즘 사용
타이틀
세부 정보
구성 요소
웹 애플리케이션
SDL 단계
빌드
적용 가능한 기술
일반
특성
해당 없음
참조
해당 없음
단계
제품에서는 승인된 MAC(메시지 인증 코드) 또는 HMAC(해시 기반 메시지 인증 코드) 알고리즘만 사용해야 합니다.
MAC는 받는 사람이 비밀 키를 사용하여 보낸 사람의 신뢰성과 메시지 무결성을 모두 확인할 수 있도록 메시지에 연결되는 정보입니다. 모든 기본 해시 또는 대칭 암호화 알고리즘을 사용하도록 승인한 경우에만 해시 기반 MAC(HMAC) 또는 블록 암호화 기반 MAC를 사용할 수 있습니다. 현재 여기에는 HMAC-SHA2 함수(HMAC-SHA256, HMAC-SHA384 및 HMAC-SHA512)과 CMAC/OMAC1 및 OMAC2 블록 암호화 기반 MAC(AES 기반)가 포함됩니다.
HMAC-SHA1은 플랫폼 호환성을 위해 사용할 수 있지만 이 절차에 대한 예외를 제출하고 조직의 Crypto 검토를 거쳐야 합니다. 128비트 미만으로의 HMAC 잘림은 허용되지 않습니다. 고객의 방법을 사용하여 키와 데이터를 해시하는 것은 승인되지 않으며 사용하기 전에 조직의 Crypto Board 검토를 거쳐야 합니다.
승인된 암호화 해시 함수만 사용
타이틀
세부 정보
구성 요소
웹 애플리케이션
SDL 단계
빌드
적용 가능한 기술
일반
특성
해당 없음
참조
해당 없음
단계
제품에서는 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 사용
암호화 알고리즘은 권한이 없는 사용자가 쉽게 바꿀 수 없는 데이터 변환을 정의합니다. SQL Server를 사용하면 관리자와 개발자가 DES, 3중 DES, TRIPLE_DES_3KEY, RC2, RC4, 128비트 RC4, DESX, 128비트 AES, 192비트 AES 및 256비트 AES를 포함한 여러 알고리즘 중에서 선택할 수 있습니다.
패키지 원본은 해당 패키지를 만든 개인이나 조직입니다. 알 수 없거나 신뢰할 수 없는 원본의 패키지를 실행하는 것은 위험할 수 있습니다. SSIS 패키지의 무단 변조를 방지하려면 디지털 서명을 사용해야 합니다. 또한 스토리지/전송 중에 패키지의 기밀성을 보장하려면 SSIS 패키지를 암호화해야 합니다.
중요한 데이터베이스 보안 개체의 무결성을 확인해야 하는 경우 디지털 서명을 사용해야 합니다. 저장 프로시저, 함수, 어셈블리 또는 트리거와 같은 데이터베이스 보안 개체는 디지털로 서명할 수 있습니다. 이러한 디지털 서명이 유용할 수 있는 경우의 예로, ISV(Independent Software Vendor)에서 고객 중 한 사람에게 전달되는 소프트웨어에 대한 지원을 제공한다고 가정해 보겠습니다. ISV는 지원을 제공하기 전에 소프트웨어의 데이터베이스 보안 개체가 실수로 또는 악의적으로 변조되지 않았는지 확인하려고 합니다. 보안 개체가 디지털 서명된 경우 ISV는 해당 디지털 서명을 확인하고 무결성의 유효성을 검사할 수 있습니다.
SQL Server EKM(확장 가능 키 관리)을 사용하면 데이터베이스 파일을 보호하는 암호화 키를 스마트 카드, USB 디바이스 또는 EKM/HSM 모듈과 같은 외부 디바이스에 저장할 수 있습니다. 데이터베이스 관리자(sysadmin 그룹의 멤버 제외)로부터 데이터를 보호할 수도 있습니다. 즉, 외부 EKM/HSM 모듈에서 데이터베이스 사용자만 액세스할 수 있는 암호화 키를 사용하여 데이터를 암호화할 수 있습니다.
데이터베이스 엔진에 암호화 키를 공개하지 않아야 하는 경우 AlwaysEncrypted 기능 사용
상시 암호화는 Azure SQL Database 또는 SQL Server 데이터베이스에 저장된 신용 카드 번호 또는 주민 등록 번호(예: 미국 사회 보장 번호)와 같은 중요한 데이터를 보호하기 위해 고안된 기능입니다. 상시 암호화를 사용하면 클라이언트에서 클라이언트 애플리케이션 내의 중요한 데이터를 암호화하고 데이터베이스 엔진(SQL Database 또는 SQL Server)에 암호화 키를 공개하지 않을 수 있습니다. 따라서 상시 암호화는 데이터를 소유하고 볼 수 있는 사용자와 데이터를 관리하지만 액세스 권한이 없는 사용자를 구별합니다.
IoT 디바이스에 안전하게 암호화 키 저장
타이틀
세부 정보
구성 요소
IoT 디바이스
SDL 단계
빌드
적용 가능한 기술
일반
특성
디바이스 OS - Windows IoT Core, 디바이스 연결 - Azure IoT 디바이스 SDK
대칭 또는 인증서 프라이빗 키는 TPM 또는 스마트 카드 칩과 같은 하드웨어로 보호된 스토리지에 안전하게 보관됩니다. Windows 10 IoT Core는 TPM의 사용자를 지원하며, 사용할 수 있는 몇 가지 호환 가능한 TPM이 있습니다. dTPM(불연속 TPM) 펌웨어 또는 불연속 TPM을 사용하는 것이 좋습니다. 소프트웨어 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);
여기서 보여주듯이 디바이스 기본 키는 코드에 없지만 TPM의 슬롯 0에 저장됩니다. TPM 디바이스는 IoT Hub에 연결하는 데 사용되는 수명이 짧은 SAS 토큰을 생성합니다.
IoT Hub 인증에 충분한 길이의 임의 대칭 키 생성
타이틀
세부 정보
구성 요소
IoT 클라우드 게이트웨이
SDL 단계
빌드
적용 가능한 기술
일반
특성
게이트웨이 선택 - Azure IoT Hub
참조
해당 없음
단계
IoT Hub는 디바이스 ID 레지스트리를 포함하고, 디바이스를 프로비전하는 동안 임의 대칭 키를 자동으로 생성합니다. Azure IoT Hub ID 레지스트리의 이 기능을 사용하여 인증에 사용되는 키를 생성하는 것이 좋습니다. 또한 IoT Hub를 사용하면 디바이스를 만드는 동안 키를 지정할 수 있습니다. 디바이스 프로비전 중에 IoT Hub 외부에서 키를 생성하는 경우 임의 대칭 키 또는 256비트 이상의 키를 만드는 것이 좋습니다.
PIN 사용이 필요하고 원격 지우기를 허용하는 디바이스 관리 정책이 있는지 확인합니다.
타이틀
세부 정보
구성 요소
Dynamics CRM 모바일 클라이언트
SDL 단계
배포
적용 가능한 기술
일반
특성
해당 없음
참조
해당 없음
단계
PIN 사용이 필요하고 원격 지우기를 허용하는 디바이스 관리 정책이 있는지 확인합니다.
PIN/암호/자동 잠금이 필요하고 모든 데이터를 암호화(예: BitLocker)하는 디바이스 관리 정책이 있는지 확인합니다.
타이틀
세부 정보
구성 요소
Dynamics CRM Outlook 클라이언트
SDL 단계
빌드
적용 가능한 기술
일반
특성
해당 없음
참조
해당 없음
단계
PIN/암호/자동 잠금이 필요하고 모든 데이터를 암호화(예: BitLocker)하는 디바이스 관리 정책이 있는지 확인합니다.