이진 파일이 영업 비밀인 뒤바뀌어서는 안되는 중요한 비즈니스 논리와 같은 중요한 정보를 포함하는 경우 난독 처리되어야 합니다. 어셈블리의 리버스 엔지니어링을 중지하는 것입니다. 이 목적을 위해 CryptoObfuscator와 같은 도구를 사용할 수 있습니다.
EFS(암호화 파일 시스템)를 사용하여 비밀 사용자 지정 데이터를 보호함
타이틀
세부 정보
구성 요소
컴퓨터 신뢰 경계
SDL 단계
빌드
적용 가능한 기술
일반
특성
해당 없음
참조
해당 없음
단계
컴퓨터에 대한 물리적 액세스를 사용하는 악의적 사용자에게서 비밀 사용자 지정 데이터를 보호하기 위해 EFS(암호화 파일 시스템)를 사용하는 것이 좋습니다.
파일 시스템의 애플리케이션에서 저장한 중요한 데이터가 암호화되었는지 확인
타이틀
세부 정보
구성 요소
컴퓨터 신뢰 경계
SDL 단계
배포
적용 가능한 기술
일반
특성
해당 없음
참조
해당 없음
단계
EFS를 적용할 수 없는 경우 파일 시스템의 애플리케이션에서 저장한 중요한 데이터가 암호화되었는지(예: DPAPI 사용) 확인합니다.
브라우저에서 중요한 콘텐츠가 캐시되지 않았는지 확인
타이틀
세부 정보
구성 요소
웹 애플리케이션
SDL 단계
빌드
적용 가능한 기술
일반, Web Forms, MVC5, MVC6
특성
해당 없음
참조
해당 없음
단계
브라우저는 캐싱 및 기록을 목적으로 정보를 저장할 수 있습니다. 이러한 캐시된 파일은 Internet Explorer의 경우 임시 인터넷 파일 폴더와 같은 폴더에 저장됩니다. 이러한 페이지를 다시 참조하는 경우 브라우저는 해당 캐시의 페이지를 표시합니다. 중요한 정보(예: 해당 주소, 신용 카드 세부 정보, 사회 보장 번호 또는 사용자 이름)를 사용자에게 표시하는 경우 이 정보를 브라우저의 캐시에 저장할 수 있습니다. 따라서 브라우저의 캐시를 검사하거나 브라우저의 "뒤로" 단추를 눌러서 검색할 수 있습니다. 캐시 제어 응답 헤더 값을 모든 페이지에 "no-store"로 설정합니다.
public override void OnActionExecuting(ActionExecutingContext filterContext)
{
if (filterContext == null || (filterContext.HttpContext != null && filterContext.HttpContext.Response != null && filterContext.HttpContext.Response.IsRequestBeingRedirected))
{
//// Since this is MVC pipeline, this should never be null.
return;
}
var attributes = filterContext.ActionDescriptor.GetCustomAttributes(typeof(System.Web.Mvc.OutputCacheAttribute), false);
if (attributes == null || **Attributes**.Count() == 0)
{
filterContext.HttpContext.Response.Cache.SetNoStore();
filterContext.HttpContext.Response.Cache.SetCacheability(HttpCacheability.NoCache);
filterContext.HttpContext.Response.Cache.SetExpires(DateTime.UtcNow.AddHours(-1));
if (!filterContext.IsChildAction)
{
filterContext.HttpContext.Response.AppendHeader("Pragma", "no-cache");
}
}
base.OnActionExecuting(filterContext);
}
Web.config, appsettings.json과 같은 구성 파일은 사용자 이름, 암호, 데이터베이스 연결 문자열 및 암호화 키를 포함하여 중요한 정보를 저장하는 데 자주 사용됩니다. 이러한 정보를 보호하지 않으면 애플리케이션은 계정 사용자 이름과 암호, 데이터베이스 이름과 서버 이름 등과 같은 중요한 정보를 얻는 공격자 또는 악의적인 사용자에 대해 취약해집니다. 배포 유형(azure/on-prem)에 따라 DPAPI 또는 Azure Key Vault와 같은 서비스를 사용하여 구성 파일의 중요한 섹션을 암호화합니다.
자동 완성 특성은 양식이 자동 완성을 사용해야 할지 여부를 지정합니다. 자동 완성이 켜져 있으면 브라우저는 사용자가 이전에 입력한 값을 기반으로 값을 자동으로 완성합니다. 예를 들어 양식에 새 이름 및 암호를 입력하고 양식을 제출하면 브라우저는 암호를 저장해야 하는지 묻습니다. 이후로 양식이 표시되면 이름 및 암호가 자동으로 채워지거나 이름을 입력하는 대로 완성합니다. 로컬 액세스 권한이 있는 공격자는 브라우저 캐시에서 일반 텍스트 암호를 얻을 수 있습니다. 기본적으로 자동 완성은 활성화되어 있으므로 명시적으로 비활성화되어야 합니다.
암호, 신용 카드 번호, SSN과 같은 중요한 데이터가 화면에 표시하는 경우 마스킹되도록 해야 합니다. 그러면 권한 없는 사용자가 데이터에 액세스하지 않도록 방지하게 됩니다(예: 어깨 너머로 알게 된 암호, 사용자의 SSN 숫자를 보는 고객 지원 담당자). 이러한 데이터 요소가 일반 텍스트로 표시되지 않고 적절하게 마스킹되도록 합니다. 이러한 항목은 입력으로 허용(예: 입력 형식="암호")하고 화면에 다시 표시(예: 신용 카드 번호의 마지막 4개 숫자만 표시)하는 동안 처리되어야 합니다.
동적 데이터 마스킹의 목적은 중요한 데이터의 노출을 제한하여 데이터에 대한 액세스 권한이 없는 사용자가 보지 못하게 하는 것이지 데이터베이스 사용자가 데이터베이스에 직접 연결하여 중요한 데이터 조각을 노출하는 과도한 쿼리를 실행하지 못하게 하는 것은 아닙니다. 동적 데이터 마스킹은 다른 SQL Server 보안 기능(감사, 암호화, 행 수준 보안...)을 보완합니다. 데이터베이스에서 중요한 데이터의 보안을 향상하기 위해 함께 이 기능을 사용하는 것이 좋습니다. 이 기능은 SQL Server 2016 이상 및 Azure SQL Database에서만 지원됩니다.
암호는 사용자 지정 사용자 저장소 데이터베이스에 저장되어야 합니다. 암호 해시는 대신 솔트 값으로 저장되어야 합니다. 사용자에 대한 솔트는 항상 고유해야 하며 무차별 암호 강제 적용 가능성을 제거하기 위해 암호를 저장하기 전에 150,000번의 루프라는 최소 작업 요소 반복 횟수로 bcrypt, scrypt 또는 PBKDF2를 적용해야 합니다.
SQL Server의 TDE(투명한 데이터 암호화) 기능을 통해 데이터베이스에서 중요한 데이터를 암호화하고 인증서를 사용하여 데이터를 암호화하는 데 사용되는 키를 보호할 수 있습니다. 그러면 키가 없는 사용자가 데이터를 사용하지 않도록 방지합니다. TDE는 데이터 및 로그 파일을 의미하는 "유휴" 데이터를 보호하고 다양한 업계에서 확립된 법, 규정 및 지침에 부합하는 기능을 제공합니다.
SQL Server에는 백업을 만드는 동안 데이터를 암호화하는 기능이 있습니다. 암호화 알고리즘 및 암호기(인증서 또는 비대칭 키)를 지정하여 백업을 만들 때 암호화된 백업 파일을 만들 수 있습니다.
Web API와 관련된 중요한 데이터가 브라우저의 스토리지에 저장되지 않았는지 확인합니다.
타이틀
세부 정보
구성 요소
웹 API
SDL 단계
빌드
적용 가능한 기술
MVC 5, MVC 6
특성
ID 공급자 - ADFS, ID 공급자 - Microsoft Entra ID
참조
해당 없음
단계
특정 구현에서 Web API의 인증과 관련된 중요한 아티팩트는 브라우저의 로컬 스토리지에 저장됩니다. 예를 들어, adal.idtoken, adal.nonce.idtoken, adal.access.token.key, adal.token.keys, adal.state.login, adal.session.state, adal.expiration.key 등과 같은 Microsoft Entra 인증 아티팩트입니다.
이러한 아티팩트는 모두 로그아웃 또는 브라우저가 닫힌 후에도 사용할 수 있습니다. 악의적 사용자가 이러한 아티팩트에 대한 액세스 권한을 가져온 경우 보호된 리소스(API)에 액세스하기 위해 다시 사용할 수 있습니다. Web API와 관련된 중요한 아티팩트가 모두 브라우저의 스토리지에 저장되지 않았는지 확인합니다. 클라이언트 쪽 스토리지를 피할 수 없는 경우(예: 암시적 OpenIdConnect/OAuth 흐름을 활용하는 SPA(단일 페이지 애플리케이션)는 액세스 토큰을 로컬로 저장함) 스토리지 선택 항목 사용은 지속성을 갖지 않습니다. 예를 들어, LocalStorage보다 SessionStorage를 선호합니다.
예시
아래 JavaScript 코드 조각은 로컬 스토리지에 인증 아티팩트를 저장하는 사용자 지정 인증 라이브러리에서 비롯됩니다. 이렇게 구현하지 않아야 합니다.
ns.AuthHelper.Authenticate = function () {
window.config = {
instance: 'https://login.microsoftonline.com/',
tenant: ns.Configurations.Tenant,
clientId: ns.Configurations.AADApplicationClientID,
postLogoutRedirectUri: window.location.origin,
cacheLocation: 'localStorage', // enable this for IE, as sessionStorage does not work for localhost.
};
Azure Cosmos DB에 저장된 중요한 데이터 암호화
타이틀
세부 정보
구성 요소
Azure Document DB
SDL 단계
빌드
적용 가능한 기술
일반
특성
해당 없음
참조
해당 없음
단계
문서 DB에서 저장하기 전에 애플리케이션 수준에서 중요한 데이터를 암호화하거나 Azure Storage 또는 Azure SQL과 같은 다른 스토리지 솔루션에서 중요한 데이터를 저장합니다.
Azure Disk Encryption을 사용하여 Virtual Machines에 사용되는 디스크 암호화
Azure 디스크 암호화는 현재 미리 보기에 포함되어 있는 새로운 기능입니다. 이 기능을 사용하면 IaaS Virtual Machine에서 사용되는 OS 디스크 및 데이터 디스크를 암호화할 수 있습니다. Windows의 경우 업계 표준의 BitLocker 암호화 기술을 사용하여 드라이브가 암호화됩니다. Linux의 경우 DM-Crypt 기술을 사용하여 디스크가 암호화됩니다. 이 기술은 Azure Key Vault와 통합되어 디스크 암호화 키를 제어 및 관리할 수 있도록 합니다. Azure 디스크 암호화 솔루션은 다음 3가지 고객 암호화 시나리오를 지원합니다.
Azure Key Vault에 저장되는 고객 암호화 VHD 파일 및 고객 제공 암호화 키에서 만든 새 IaaS VM에 대해 암호화를 사용하도록 설정합니다.
Azure Marketplace에서 만든 새 IaaS VM에 대해 암호화를 사용하도록 설정합니다.
미사용 데이터에 대한 Azure Storage 서비스 암호화(SSE)를 사용하면 조직의 보안 및 규정 준수 약정에 맞게 데이터를 보호할 수 있습니다. 이 기능을 통해 Azure Storage는 스토리지를 유지하기 전에 데이터를 자동으로 암호화하고 검색하기 전에 암호를 해독합니다. 암호화, 암호 해독 및 키 관리는 사용자에게 완전히 투명하게 처리됩니다. SSE는 블록 Blob, 페이지 Blob 및 추가 Blob에만 적용됩니다. 테이블, 큐 및 파일을 비롯한 다른 유형의 데이터는 암호화되지 않습니다.
워크플로 암호화 및 암호 해독:
고객이 스토리지 계정에 대해 암호화를 설정합니다.
고객이 새 데이터(PUT Blob, PUT 블록, PUT 페이지 등)를 Blob Storage에 기록할 경우 모든 기록 내용이 가장 강력한 블록 암호화 중 하나인 256비트 AES 암호화를 사용하여 암호화됩니다.
고객이 데이터(GET Blob 등)에 액세스해야 하는 경우 사용자에게 반환되기 전에 데이터가 자동으로 해독됩니다.
암호화를 사용하지 않도록 설정하면 새로운 기록 내용은 더 이상 암호화되지 않으며 기존 암호화된 데이터는 사용자가 다시 작성할 때까지 암호화된 상태로 유지됩니다. 암호화를 사용하는 동안 Blob Storage에 기록된 내용이 암호화됩니다. 스토리지 계정에 대해 암호화를 사용/사용하지 않는 것으로 사용자 전환하는 것으로 데이터의 상태는 변경되지 않습니다.
모든 암호화 키는 Microsoft에서 저장하고 암호화하며 관리합니다.
현재 암호화에 사용되는 키는 Microsoft에서 관리합니다. Microsoft에서는 처음에 키를 생성한 후에, 내부 Microsoft 정책에 정의된 대로 키의 정기적인 순환뿐 아니라 보안 스토리지도 관리합니다. 나중에 고객은 고유한 암호화 키를 관리하는 기능을 사용할 수 있게 되며 Microsoft에서 관리하는 키에서 고객이 관리하는 키로 마이그레이션 경로를 제공할 예정입니다.
.NET용 Azure Storage 클라이언트 라이브러리 Nuget 패키지는 Azure Storage에 업로드하기 전에 클라이언트 애플리케이션 내에서 데이터를 암호화하고 클라이언트로 다운로드하는 동안 데이터를 해독하는 기능을 지원합니다. 라이브러리 또한 스토리지 계정 키 관리를 위해 Azure Key Vault와의 통합을 지원합니다. 클라이언트 쪽 암호화의 작동 원리에 대한 간단한 설명은 다음과 같습니다.
그런 다음 키 암호화 KEK를 사용하여 CEK를 래핑(암호화)합니다. KEK는 키 식별자로 식별되고 비대칭 키 쌍 또는 대칭 키일 수 있으며 로컬로 관리되거나 Azure Key Vault에 저장됩니다. Storage 클라이언트 자체는 KEK에 액세스할 수 없습니다. 단지 키 자격 증명 모음에서 제공되는 키 래핑 알고리즘을 호출할 뿐입니다. 고객은 원하는 경우 키 래핑/래핑 해제를 위해 사용자 지정 공급자를 사용하도록 선택할 수 있습니다.
그런 다음 암호화된 데이터를 Azure Storage 서비스에 업로드합니다. 자세한 구현 세부 정보는 참조 섹션의 링크를 확인하세요.
애플리케이션이 모바일의 파일 시스템에 사용자의 PII(이메일, 전화 번호, 이름, 성, 선호도 등)와 같은 중요한 정보를 기록하는 경우 로컬 파일 시스템에 쓰기 전에 암호화되어야 합니다. 엔터프라이즈 애플리케이션인 애플리케이션을 사용하는 경우 Windows Intune을 사용하여 애플리케이션을 게시하는 가능성을 탐색합니다.
예시
Intune은 중요한 데이터를 보호하는 다음과 같은 보안 정책을 사용하여 구성될 수 있습니다.
Require encryption on mobile device
Require encryption on storage cards
Allow screen capture
예시
엔터프라이즈 애플리케이션이 아닌 애플리케이션을 사용하는 경우 파일 시스템에서 수행될 수 있는 암호화 작업을 사용하여 플랫폼 제공 키 스토리지, 키 집합을 사용하여 암호화 키를 저장합니다. 다음 코드 조각에서는 xamarin을 사용하는 키 집합에서 키에 액세스하는 방법을 보여 줍니다.
protected static string EncryptionKey
{
get
{
if (String.IsNullOrEmpty(_Key))
{
var query = new SecRecord(SecKind.GenericPassword);
query.Service = NSBundle.MainBundle.BundleIdentifier;
query.Account = "UniqueID";
NSData uniqueId = SecKeyChain.QueryAsData(query);
if (uniqueId == null)
{
query.ValueData = NSData.FromString(System.Guid.NewGuid().ToString());
var err = SecKeyChain.Add(query);
_Key = query.ValueData.ToString();
}
else
{
_Key = uniqueId.ToString();
}
}
return _Key;
}
}
암호화되지 않은 채널을 통해 일반 텍스트 암호를 사용한 UsernameToken를 사용하면 SOAP 메시지를 찾아낼 수 있는 공격자에게 암호를 노출하게 됩니다. UsernameToken를 사용하는 서비스 공급자는 일반 텍스트로 전송된 암호를 허용할 수 있습니다. 암호화되지 않은 채널을 통해 일반 텍스트 암호는 보내면 SOAP 메시지를 찾아낼 수 있는 공격자에게 자격 증명을 노출할 수 있습니다.
둘 다. 전송 및 메시지 수준 보안(MSMQ에서만 지원됨)에 대한 설정을 제공할 수 있습니다.
TransportWithMessageCredential. 자격 증명은 메시지 및 메시지 보호를 사용하여 전달되고 서버 인증은 전송 계층에서 제공합니다.
TransportCredentialOnly. 클라이언트 자격 증명은 전송 계층으로 전달되고 메시지 보호가 적용되지 않습니다. 전송 및 메시지 보안을 사용하여 메시지의 무결성 및 기밀성을 보호합니다. 아래 구성에서는 서비스가 메시지 자격 증명과 함께 전송 보안을 사용하도록 지시합니다.