ASP.NET Core 데이터 보호를 구성 합니다.Configure ASP.NET Core Data Protection

작성자: Rick AndersonBy Rick Anderson

데이터 보호 시스템이 초기화 될 때, 운영 환경에 따른 기본 설정 이 적용됩니다.When the Data Protection system is initialized, it applies default settings based on the operational environment. 대부분 이런 기본 설정은 단일 컴퓨터에서 실행되는 앱에 적합합니다.These settings are generally appropriate for apps running on a single machine. 개발자는 기본 설정을 변경 해야 할 수는 있는 경우가 있습니다.There are cases where a developer may want to change the default settings:

  • 여러 컴퓨터 간에 분산 되는 앱입니다.The app is spread across multiple machines.
  • 준수 이유 때문입니다.For compliance reasons.

이러한 시나리오에 대 한 데이터 보호 시스템 풍부한 구성 API를 제공합니다.For these scenarios, the Data Protection system offers a rich configuration API.

경고

마찬가지로 구성 파일, 데이터 보호 키 링 보호 해야 적절 한 사용 권한을 사용 합니다.Similar to configuration files, the data protection key ring should be protected using appropriate permissions. 을 미사용 키를 암호화 하도록 선택할 수 있습니다 하지만이 되지 않도록 공격자가 새 키를 만드는 합니다.You can choose to encrypt keys at rest, but this doesn't prevent attackers from creating new keys. 따라서 응용 프로그램의 보안이 저하 됩니다.Consequently, your app's security is impacted. 데이터 보호를 사용 하 여 구성 저장소 위치는 응용 프로그램 구성 파일을 보호 하는 방식과 유사 하 게 자체가으로 제한 된 액세스 권한이 있어야 합니다.The storage location configured with Data Protection should have its access limited to the app itself, similar to the way you would protect configuration files. 예를 들어 키 링 디스크에 저장 하려는 경우에 파일 시스템 권한을 사용 합니다.For example, if you choose to store your key ring on disk, use file system permissions. id만 보장 웹 앱에서 실행 되는 대 한 읽기, 쓰기 및 해당 디렉터리에 대 한 액세스를 만듭니다.Ensure only the identity under which your web app runs has read, write, and create access to that directory. Azure 테이블 저장소를 사용 하는 경우 웹 앱에만 읽기, 쓰기 또는 등 테이블 저장소에 새 항목을 만들 수가 있어야 합니다.If you use Azure Table Storage, only the web app should have the ability to read, write, or create new entries in the table store, etc.

확장 메서드 AddDataProtection 반환는 IDataProtectionBuilder합니다.The extension method AddDataProtection returns an IDataProtectionBuilder. IDataProtectionBuilder 는 함께 연이어 호출해서 데이터 보호 옵션을 구성할 수 있는 확장 메서드들을 노출합니다. IDataProtectionBuilder exposes extension methods that you can chain together to configure Data Protection options.

ProtectKeysWithAzureKeyVaultProtectKeysWithAzureKeyVault

키를 저장할 Azure 키 자격 증명 모음, 시스템 구성 ProtectKeysWithAzureKeyVaultStartup 클래스:To store keys in Azure Key Vault, configure the system with ProtectKeysWithAzureKeyVault in the Startup class:

public void ConfigureServices(IServiceCollection services)
{
services.AddDataProtection()
.PersistKeysToAzureBlobStorage(new Uri("<blobUriWithSasToken>"))
.ProtectKeysWithAzureKeyVault("<keyIdentifier>", "<clientId>", "<clientSecret>");
}

키 링 저장소 위치 설정 (예를 들어 PersistKeysToAzureBlobStorage).Set the key ring storage location (for example, PersistKeysToAzureBlobStorage). 호출 하기 때문에 위치를 설정 해야 ProtectKeysWithAzureKeyVault 구현 하는 IXmlEncryptor 키 링 저장소 위치를 포함 한 데이터 자동 보호 설정을 사용 하지 않도록 설정 하는 합니다.The location must be set because calling ProtectKeysWithAzureKeyVault implements an IXmlEncryptor that disables automatic data protection settings, including the key ring storage location. 앞의 예제에서는 키 링을 유지 하기 위해 Azure Blob 저장소를 사용 합니다.The preceding example uses Azure Blob Storage to persist the key ring. 자세한 내용은 참조 키 저장소 공급자: Azure와 Redis합니다.For more information, see Key storage providers: Azure and Redis. 사용 하 여 로컬로 키 링을 유지할 수 있습니다 PersistKeysToFileSystem합니다.You can also persist the key ring locally with PersistKeysToFileSystem.

keyIdentifier 는 키 암호화에 사용 되는 주요 자격 증명 모음 키 식별자 (예를 들어 https://contosokeyvault.vault.azure.net/keys/dataprotection/).The keyIdentifier is the key vault key identifier used for key encryption (for example, https://contosokeyvault.vault.azure.net/keys/dataprotection/).

ProtectKeysWithAzureKeyVault 오버 로드:ProtectKeysWithAzureKeyVault overloads:

PersistKeysToFileSystemPersistKeysToFileSystem

기본 위치인 %LOCALAPPDATA% 대신 UNC 공유에 키를 저장하려면 PersistKeysToFileSystem을 이용해서 다음과 같이 시스템을 구성합니다.To store keys on a UNC share instead of at the %LOCALAPPDATA% default location, configure the system with PersistKeysToFileSystem:

public void ConfigureServices(IServiceCollection services)
{
    services.AddDataProtection()
        .PersistKeysToFileSystem(new DirectoryInfo(@"\\server\share\directory\"));
}

경고

키의 저장 위치를 변경하면 데이터 보호 시스템이 더 이상 저장된 비활성 키를 자동으로 암호화하지 않는데, 이는 DPAPI가 적절한 암호화 메커니즘인지 판단하기가 곤란하기 때문입니다.If you change the key persistence location, the system no longer automatically encrypts keys at rest, since it doesn't know whether DPAPI is an appropriate encryption mechanism.

ProtectKeysWith*ProtectKeysWith*

ProtectKeysWith* 구성 API들 중 하나를 호출하면 시스템이 저장된 비활성 키를 보호하도록 구성할 수 있습니다.You can configure the system to protect keys at rest by calling any of the ProtectKeysWith* configuration APIs. 다음 예제는 키를 UNC 공유에 저장하고 특정 X.509 인증서를 이용해서 저장된 비활성 키를 암호화합니다.Consider the example below, which stores keys on a UNC share and encrypts those keys at rest with a specific X.509 certificate:

public void ConfigureServices(IServiceCollection services)
{
    services.AddDataProtection()
        .PersistKeysToFileSystem(new DirectoryInfo(@"\\server\share\directory\"))
        .ProtectKeysWithCertificate("thumbprint");
}

내장 키 암호화 메커니즘에 대한 더 많은 예제와 설명은 비활성 키 암호화를 참고하시기 바랍니다.See Key Encryption At Rest for more examples and discussion on the built-in key encryption mechanisms.

SetDefaultKeyLifetimeSetDefaultKeyLifetime

키의 기본 수명인 90일 대신 14일의 키 수명을 사용하도록 시스템을 구성하려면 SetDefaultKeyLifetime을 사용합니다.To configure the system to use a key lifetime of 14 days instead of the default 90 days, use SetDefaultKeyLifetime:

public void ConfigureServices(IServiceCollection services)
{
    services.AddDataProtection()
        .SetDefaultKeyLifetime(TimeSpan.FromDays(14));
}

SetApplicationNameSetApplicationName

데이터 보호 시스템은 기본적으로 앱들이 동일한 물리적 키 저장소를 공유하는 경우에도 앱들을 서로 격리합니다.By default, the Data Protection system isolates apps from one another, even if they're sharing the same physical key repository. 따라서 앱들은 서로 다른 앱이 보호한 페이로드를 이해할 수 없습니다.This prevents the apps from understanding each other's protected payloads. 서로 다른 두 앱 간에 보호된 페이로드를 공유하려면, 각 앱 모두에서 SetApplicationName 을 이용해서 동일한 앱 이름을 전달하여 시스템을 구성해야 합니다.To share protected payloads between two apps, use SetApplicationName with the same value for each app:

public void ConfigureServices(IServiceCollection services)
{
    services.AddDataProtection()
        .SetApplicationName("shared app name");
}

DisableAutomaticKeyGenerationDisableAutomaticKeyGeneration

키 만료가 다가오더라도 앱이 자동으로 키를 롤링하지 않도록 (새로운 키를 생성하지 않도록) 구성해야 하는 시나리오도 있을 수 있습니다.You may have a scenario where you don't want an app to automatically roll keys (create new keys) as they approach expiration. 한 가지 사례는 앱들이 주/보조 관계를 갖도록 설정되어 있어서 주 앱만 키 관리 작업을 수행하고 나머지 모든 보조 앱들은 단순히 키 링의 읽기 전용 뷰만 갖고 있는 경우입니다.One example of this might be apps set up in a primary/secondary relationship, where only the primary app is responsible for key management concerns and secondary apps simply have a read-only view of the key ring. 그런 경우에는 DisableAutomaticKeyGeneration으로 보조 앱은 키 링을 읽기 전용으로만 처리하도록 시스템을 구성할 수 있습니다.The secondary apps can be configured to treat the key ring as read-only by configuring the system with DisableAutomaticKeyGeneration:

public void ConfigureServices(IServiceCollection services)
{
    services.AddDataProtection()
        .DisableAutomaticKeyGeneration();
}

응용 프로그램 격리Per-application isolation

ASP.NET Core 호스트에 의해서 데이터 보호 시스템이 제공되는 경우, 여러 앱이 동일한 작업자 프로세스 계정으로 실행되고 동일한 마스터 키 관련 자료를 사용하더라도 서로 자동으로 격리됩니다When the Data Protection system is provided by an ASP.NET Core host, it automatically isolates apps from one another, even if those apps are running under the same worker process account and are using the same master keying material. 이런 특징은 System.Web의 <machineKey > 요소에서 제공되는 IsolateApps 한정자의 동작과 다소 유사합니다.This is somewhat similar to the IsolateApps modifier from System.Web's <machineKey> element.

이 격리 메커니즘은 로컬 컴퓨터의 각 응용 프로그램들을 고유한 테넌트로 간주하는 방식으로 동작하며, 따라서 해당하는 모든 응용 프로그램에 루트로 제공되는 IDataProtector 에는 자동으로 응용 프로그램 ID가 판별자로 포함됩니다.The isolation mechanism works by considering each app on the local machine as a unique tenant, thus the IDataProtector rooted for any given app automatically includes the app ID as a discriminator. 여기에 사용되는 응용 프로그램 고유 ID는 다음 두 가지 방법 중 한 가지 방식으로 얻어집니다.The app's unique ID comes from one of two places:

  1. 응용 프로그램이 IIS에서 호스트 될 경우, 응용 프로그램의 구성 경로가 고유 식별자로 사용됩니다.If the app is hosted in IIS, the unique identifier is the app's configuration path. 만약 응용 프로그램이 팜 환경에 배포된다면 팜에 포함된 모든 컴퓨터 간에 IIS 환경이 비슷하게 구성되었다는 전제하에 이 값이 일정해야 합니다.If an app is deployed in a web farm environment, this value should be stable assuming that the IIS environments are configured similarly across all machines in the web farm.

  2. 응용 프로그램이 IIS에서 호스트 되지 않을 경우, 응용 프로그램의 물리적 경로가 고유 식별자로 사용됩니다.If the app isn't hosted in IIS, the unique identifier is the physical path of the app.

고유 식별자 다시 설정 후에 유지 하도록 되어 — 개별 응용 프로그램 및 컴퓨터 자체입니다.The unique identifier is designed to survive resets — both of the individual app and of the machine itself.

이 격리 메커니즘은 응용 프로그램에 악의적인 의사가 없음을 전제로 합니다.This isolation mechanism assumes that the apps are not malicious. 악의적인 응용 프로그램은 언제든지 동일한 작업자 프로세스 계정으로 동작하는 다른 모든 응용 프로그램에 영향을 미칠 수 있습니다.A malicious app can always impact any other app running under the same worker process account. 응용 프로그램들 간에 서로 신뢰할 수 없는 공유 호스팅 환경에서는 호스팅 공급자가 응용 프로그램의 기본 키 저장소를 분리하는 등, OS 수준에서 응용 프로그램 간에 격리를 담보할 수 있는 조치를 취해야만 합니다. In a shared hosting environment where apps are mutually untrusted, the hosting provider should take steps to ensure OS-level isolation between apps, including separating the apps' underlying key repositories.

데이터 보호 시스템이 ASP.NET Core 호스트에 의해 제공되지 않는 경우에는 (가령, 개발자가 직접 구체적인 DataProtectionProvider 형식을 이용해서 인스턴스를 생성하는 등),If the Data Protection system isn't provided by an ASP.NET Core host (for example, if you instantiate it via the DataProtectionProvider concrete type) app isolation is disabled by default. 자동으로 응용 프로그램 격리가 비활성화되며 적절한 용도를 제공하기만 하면 동일한 키 관련 자료를 사용하는 모든 응용 프로그램들 간에 페이로드를 공유할 수 있습니다.When app isolation is disabled, all apps backed by the same keying material can share payloads as long as they provide the appropriate purposes. 이런 환경에서 응용 프로그램 간 격리를 제공하려면 앞에서 살펴본 예제처럼 구성 개체의 SetApplicationName 메서드를 호출하면 됩니다.To provide app isolation in this environment, call the SetApplicationName method on the configuration object and provide a unique name for each app.

UseCryptographicAlgorithms으로 알고리즘 변경하기Changing algorithms with UseCryptographicAlgorithms

새로 생성된 키에 의해 사용되는 데이터 보호 스택의 기본 알고리즘을 변경할 수도 있습니다.The Data Protection stack allows you to change the default algorithm used by newly-generated keys. 이 작업을 수행하는 가장 간단한 방법은 구성 콜백에서 UseCryptographicAlgorithms 을 호출하는 것입니다.The simplest way to do this is to call UseCryptographicAlgorithms from the configuration callback:

services.AddDataProtection()
    .UseCryptographicAlgorithms(
        new AuthenticatedEncryptorConfiguration()
    {
        EncryptionAlgorithm = EncryptionAlgorithm.AES_256_CBC,
        ValidationAlgorithm = ValidationAlgorithm.HMACSHA256
    });

EncryptionAlgorithm 및 ValidationAlgorithm의 기본값은 각각 AES-256-CBC와 HMACSHA256 입니다.The default EncryptionAlgorithm is AES-256-CBC, and the default ValidationAlgorithm is HMACSHA256. 시스템 관리자가 컴퓨터 수준 정책을 통해서 기본 정책을 설정할 수도 있지만, 명시적으로 UseCryptographicAlgorithms를 호출하면 기본 정책이 재정의됩니다.The default policy can be set by a system administrator via a machine-wide policy, but an explicit call to UseCryptographicAlgorithms overrides the default policy.

UseCryptographicAlgorithms 을 호출하면 미리 제공되는 목록 중에서 원하는 알고리즘을 지정할 수 있습니다.Calling UseCryptographicAlgorithms allows you to specify the desired algorithm from a predefined built-in list. 개발자는 알고리즘 구현을 걱정할 필요가 없습니다.You don't need to worry about the implementation of the algorithm. 위의 시나리오에서 데이터 보호 시스템이 Windows에서 실행 중이라면 AES의 CNG 구현을 사용하려고 시도하고, In the scenario above, the Data Protection system attempts to use the CNG implementation of AES if running on Windows. 그렇지 않으면 관리되는 System.Security.Cryptography.Aes 클래스로 대체됩니다.Otherwise, it falls back to the managed System.Security.Cryptography.Aes class.

UseCustomCryptographicAlgorithms를 호출해서 원하는 구현을 직접 지정할 수도 있습니다.You can manually specify an implementation via a call to UseCustomCryptographicAlgorithms.

알고리즘을 변경하더라도 키 링에 존재하는 기존 키에는 영향을 주지 않습니다.Changing algorithms doesn't affect existing keys in the key ring. 알고리즘 변경은 새로 생성되는 키에만 영향을 줍니다.It only affects newly-generated keys.

관리되는 사용자 지정 알고리즘 지정하기Specifying custom managed algorithms

관리 되는 사용자 지정 알고리즘을 지정 하려면 만듭니다는 ManagedAuthenticatedEncryptorConfiguration 구현 형식을 가리키는 인스턴스:To specify custom managed algorithms, create a ManagedAuthenticatedEncryptorConfiguration instance that points to the implementation types:

serviceCollection.AddDataProtection()
    .UseCustomCryptographicAlgorithms(
        new ManagedAuthenticatedEncryptorConfiguration()
    {
        // A type that subclasses SymmetricAlgorithm
        EncryptionAlgorithmType = typeof(Aes),

        // Specified in bits
        EncryptionAlgorithmKeySize = 256,

        // A type that subclasses KeyedHashAlgorithm
        ValidationAlgorithmType = typeof(HMACSHA256)
    });

일반적으로 *Type 속성들은 구체적이고 인스턴스를 생성할 수 있는 (매개변수가 없는 public 생성자를 통해서) SymmetricAlgorithmKeyedHashAlgorithm의 구현을 가리켜야 하지만, 시스템 상 특수한 경우에는 편의를 위해 typeof(Aes) 같은 특정 값들을 지정하기도 합니다Generally the *Type properties must point to concrete, instantiable (via a public parameterless ctor) implementations of SymmetricAlgorithm and KeyedHashAlgorithm, though the system special-cases some values like typeof(Aes) for convenience.

참고

SymmetricAlgorithm 은 반드시 키 길이가 128 비트 이상이고 블럭 크키가 64 비트 이상이어야 하며, PKCS #7 패딩을 사용하는 CBC 모드 암호화를 지원해야 합니다.The SymmetricAlgorithm must have a key length of ≥ 128 bits and a block size of ≥ 64 bits, and it must support CBC-mode encryption with PKCS #7 padding. KeyedHashAlgorithm 은 다이제스트 크기가 128 비트 이상이어야 하고, 해시 알고리즘의 다이제스트 길이와 동일한 키 길이를 지원해야 합니다The KeyedHashAlgorithm must have a digest size of >= 128 bits, and it must support keys of length equal to the hash algorithm's digest length. KeyedHashAlgorithm 이 반드시 HMAC여야 할 필요는 없습니다The KeyedHashAlgorithm isn't strictly required to be HMAC.

사용자 지정 Windows CNG 알고리즘 지정하기Specifying custom Windows CNG algorithms

CBC 모드 암호화 + HMAC 유효성 검사를 사용하는 사용자 지정 Windows CNG 알고리즘을 지정하려면, 알고리즘 정보를 담고 있는 CngCbcAuthenticatedEncryptorConfiguration의 인스턴스를 생성합니다To specify a custom Windows CNG algorithm using CBC-mode encryption with HMAC validation, create a CngCbcAuthenticatedEncryptorConfiguration instance that contains the algorithmic information:

services.AddDataProtection()
    .UseCustomCryptographicAlgorithms(
        new CngCbcAuthenticatedEncryptorConfiguration()
    {
        // Passed to BCryptOpenAlgorithmProvider
        EncryptionAlgorithm = "AES",
        EncryptionAlgorithmProvider = null,

        // Specified in bits
        EncryptionAlgorithmKeySize = 256,

        // Passed to BCryptOpenAlgorithmProvider
        HashAlgorithm = "SHA256",
        HashAlgorithmProvider = null
    });

참고

대칭형 블럭 암호화 알고리즘(Symmetric Block Cipher Algorithm)은 반드시 키 길이가 128 비트 이상이고 블럭 크키가 64 비트 이상이어야 하며, PKCS #7 패딩을 사용하는 CBC 모드 암호화를 지원해야 합니다.The symmetric block cipher algorithm must have a key length of >= 128 bits, a block size of >= 64 bits, and it must support CBC-mode encryption with PKCS #7 padding. 해시 알고리즘은 다이제스트 크기가 128 비트 이상이어야 하고, BCRYPT_ALG_HANDLE_HMAC_FLAG 플래그로 시작할 수 있도록 지원해야 합니다.The hash algorithm must have a digest size of >= 128 bits and must support being opened with the BCRYPT_ALG_HANDLE_HMAC_FLAG flag. *Provider 속성들을 null로 설정해서 지정된 알고리즘에 대한 기본 공급자를 사용할 수 있습니다.The *Provider properties can be set to null to use the default provider for the specified algorithm. 보다 자세한 정보는 BCryptOpenAlgorithmProvider 를 참고하시기 바랍니다.See the BCryptOpenAlgorithmProvider documentation for more information.

갈루아(Galois)/카운터 모드 암호화 + 유효성 검사를 사용하는 사용자 지정 Windows CNG 알고리즘을 지정하려면, 알고리즘 정보를 담고 있는 CngGcmAuthenticatedEncryptorConfiguration 의 인스턴스를 생성합니다.To specify a custom Windows CNG algorithm using Galois/Counter Mode encryption with validation, create a CngGcmAuthenticatedEncryptorConfiguration instance that contains the algorithmic information:

services.AddDataProtection()
    .UseCustomCryptographicAlgorithms(
        new CngGcmAuthenticatedEncryptorConfiguration()
    {
        // Passed to BCryptOpenAlgorithmProvider
        EncryptionAlgorithm = "AES",
        EncryptionAlgorithmProvider = null,

        // Specified in bits
        EncryptionAlgorithmKeySize = 256
    });

참고

대칭형 블럭 암호화 알고리즘(Symmetric Block Cipher Algorithm)은 반드시 키 길이가 128 비트 이상이고 블럭 크키가 정확히 128 비트여야 하며, GCM 암호화를 지원해야 합니다.The symmetric block cipher algorithm must have a key length of >= 128 bits, a block size of exactly 128 bits, and it must support GCM encryption. EncryptionAlgorithmProvider 속성을 null로 설정해서 지정된 알고리즘에 대한 기본 공급자를 사용할 수 있습니다.You can set the EncryptionAlgorithmProvider property to null to use the default provider for the specified algorithm. 보다 자세한 정보는 BCryptOpenAlgorithmProvider 를 참고하시기 바랍니다.See the BCryptOpenAlgorithmProvider documentation for more information.

다른 사용자 지정 알고리즘 지정하기Specifying other custom algorithms

기본적인 API로 제공되지는 않지만 데이터 보호 시스템은 거의 모든 유형의 알고리즘을 지정할 수 있도록 충분한 확장이 가능합니다.Though not exposed as a first-class API, the Data Protection system is extensible enough to allow specifying almost any kind of algorithm. 예를 들어서, 하드웨어 보안 모듈 (HSM) 내에 포함된 모든 키들을 유지하고, 핵심 암호화 및 복호화 루틴의 사용자 지정 구현을 제공하는 것도 가능합니다.For example, it's possible to keep all keys contained within a Hardware Security Module (HSM) and to provide a custom implementation of the core encryption and decryption routines. 보다 자세한 정보는 핵심 암호화 확장성(Core Cryptography Extensibility)IAuthenticatedEncryptor 절을 참고하시기 바랍니다.See IAuthenticatedEncryptor in Core cryptography extensibility for more information.

Docker 컨테이너에서 호스팅할 때 키 유지하기Persisting keys when hosting in a Docker container

Docker 컨테이너에서 호스팅할 경우, 다음 중 한 곳에 키를 저장해야 합니다.When hosting in a Docker container, keys should be maintained in either:

  • 공유 볼륨이나 호스트 탑재 볼륨 같이 컨테이너의 수명과 무관하게 유지되는 Docker 볼륨의 폴더A folder that's a Docker volume that persists beyond the container's lifetime, such as a shared volume or a host-mounted volume.
  • Azure 키 자격 증명 모음 또는 Redis와 같은 외부 공급자An external provider, such as Azure Key Vault or Redis.

참고자료See also