다음을 통해 공유

보안 Windows 앱 개발 소개

  • 아티클

이 소개 문서는 앱 설계자 및 개발자가 UWP(보안 Universal Windows Platform) 앱을 빠르게 만드는 다양한 Windows 10 플랫폼 기능을 더 잘 이해하는 데 도움이 됩니다. 이 소개 문서는 인증, 전송 중인 데이터 및 미사용 데이터와 같은 각 단계에서 사용할 수 있는 Windows 보안 기능을 사용하는 방법을 자세히 설명합니다. 각 챕터에 포함된 추가 리소스를 검토하여 각 토픽에 대한 자세한 정보를 찾을 수 있습니다.

1 소개

보안 앱 개발은 어려울 수 있습니다. 오늘날 빠르게 변화하는 모바일, 소셜, 클라우드 및 복잡한 엔터프라이즈 앱 환경에서 고객은 그 어느 때보다 빠르게 앱이 사용 가능해지고 업데이트되기를 기대합니다. 또한 고객은 다양한 형식의 장치를 사용하며 앱 환경을 만드는 복잡성을 더합니다. Windows 유니버설 Windows 플랫폼(UWP)용으로 빌드하는 경우 기존 데스크톱, 랩톱, 태블릿 및 모바일 장치 목록과 사물 인터넷, Xbox One, Microsoft Surface Hub 및 HoloLens를 아우르는 새로운 디바이스 목록이 늘어나고 있습니다. 개발자는 관련된 모든 플랫폼 또는 장치에서 앱이 데이터를 안전하게 통신하고 저장하도록 해야 합니다.

Windows 보안 기능을 활용할 때의 이점은 다음과 같습니다.

  • 보안 구성 요소 및 기술에 일관된 API를 사용하여 Windows를 지원하는 모든 디바이스에서 표준화된 보안을 갖게 됩니다.
  • 이러한 보안 시나리오를 다루는 사용자 지정 코드를 구현한 경우보다 적은 코드를 작성하고, 테스트하며 유지합니다.
  • 운영 체제를 사용하여 앱이 리소스 및 로컬 또는 원격 시스템 리소스에 액세스하는 방법을 제어하기 때문에 앱은 더 안정적이고 안전해집니다.

인증하는 동안, 특정 서비스에 대한 액세스를 요청하는 사용자의 ID의 유효성이 검사됩니다. Windows Hello는 Windows 앱에서 보다 안전한 인증 메커니즘을 만드는 데 도움이 되는 Windows의 구성 요소입니다. PIN(개인 식별 번호) 또는 사용자의 지문, 얼굴 또는 홍채 같은 생체 인식을 사용하여 앱에 대한 다단계 인증을 구현할 수 있습니다.

전송 중인 데이터는 연결 및 연결 간에 전송된 메시지를 나타냅니다. 예를 들어 원격 서버에서 웹 서비스를 사용하여 데이터를 검색합니다. SSL(Secure Sockets Layer) 및 HTTPS(Secure Hypertext Transfer Protocol)를 사용하면 연결의 보안이 보장됩니다. 중간 당사자가 이러한 메시지에 액세스하지 못하도록 하거나 권한이 없는 앱이 웹 서비스와 통신하지 못하도록 방지하는 것은 전송 중인 데이터를 보호하는 데 중요합니다.

마지막으로 미사용 데이터는 메모리 또는 스토리지 미디어에 있는 데이터와 관련이 있습니다. Windows 앱에는 앱 간의 무단 데이터 액세스를 방지하고 디바이스에서 데이터를 더욱 안전하게 보호하기 위한 암호화 API를 제공하는 앱 모델이 있습니다. 자격 증명 보관이라는 기능을 사용하여 장치에 사용자 자격 증명을 안전하게 저장하고 운영 체제에서 다른 앱이 액세스하지 못하도록 할 수 있습니다.

2 인증 요소

데이터를 보호하려면, 액세스 권한을 요청하는 사용자를 식별하고 요청하는 데이터 리소스에 액세스할 수 있는 권한을 부여받아야 합니다. 사용자를 식별하는 프로세스를 인증이라고 부르며, 리소스에 대한 액세스 권한을 결정하는 프로세스를 권한 부여라고 부릅니다. 이러한 작업은 밀접하게 관련된 작업이며, 사용자와 구별할 수 없습니다. 데이터가 한 서버에 상주하는지 아니면 여러 시스템에 분산되어 있는지와 같은 여러 요인에 따라, 이는 비교적 간단하거나 복잡한 작업이 될 수 있습니다. 인증 및 권한 부여 서비스를 제공하는 서버를 ID 공급자라고 합니다.

사용자는 특정 서비스 및/또는 앱으로 자신을 인증하기 위해 알고 있는 것, 가지고 있는 것 및/또는 다른 것으로 구성된 자격 증명을 사용합니다. 이러한 각 요소를 인증 요소라고 합니다.

  • 사용자가 알고 있는 것은 일반적으로 암호이지만 PIN(개인 식별 번호) 또는 "비밀" 질문 및 답변 쌍일 수도 있습니다.
  • 사용자가 가지고 있는 것은 가장 자주 사용자에게 고유한 인증 데이터를 포함하는 USB 스틱과 같은 하드웨어 메모리 디바이스입니다.
  • 사용자가 지문을 포괄하는 경우가 많지만 사용자의 음성, 얼굴, 안구(눈) 특성 또는 동작 패턴과 같은 점점 더 인기 있는 요인이 있습니다. 데이터로 저장되는 경우, 이러한 측정값을 생체 인식이라고 합니다.

사용자가 만든 암호는 그 자체로 인증 요소이지만, 충분하지 않은 경우가 많습니다. 암호를 아는 사람은 누구나 암호를 소유한 사용자를 가장할 수 있습니다. 스마트 카드는 더 높은 수준의 보안을 제공할 수 있지만 도난, 분실 또는 잘못 배치되는 경우가 있을 수도 있습니다. 지문 또는 안구 스캔으로 사용자를 인증할 수 있는 시스템은 가장 높고 편리한 수준의 보안을 제공할 수 있지만, 모든 사용자가 사용할 수 없는 고가의 특수 하드웨어(예시: 얼굴 인식용 Intel RealSense 카메라)가 필요합니다.

시스템에서 사용하는 인증 방법을 디자인하는 것은 데이터 보안의 복잡하고 중요한 측면입니다. 일반적으로 인증에 사용하는 요인이 많을수록 시스템의 보안이 강화됩니다. 동시에 인증을 사용할 수 있어야 합니다. 사용자는 일반적으로 하루에 여러 번 로그인하므로 프로세스가 빨라야 합니다. 인증 유형을 선택하는 것은 보안과 사용 편의성 간의 절상입니다. 단일 단계 인증은 가장 안전하고 사용하기 쉬운 인증이며, 다단계 인증은 더 안전해지지만 더 많은 요소가 추가됨에 따라 더 복잡해집니다.

2.1 단일 단계 인증

이 인증 형식은 단일 사용자 자격 증명을 기반으로 합니다. 일반적으로 암호이지만 PIN(개인 식별 번호)일 수도 있습니다.

단일 단계 인증 프로세스는 다음과 같습니다.

  • 사용자는 ID 공급자에게 사용자 이름과 암호를 제공합니다. ID 공급자는 사용자의 ID를 확인하는 서버 프로세스입니다.
  • ID 공급자는 사용자 이름과 암호가 시스템에 저장된 것과 같은지 여부를 검사합니다. 대부분의 경우, 암호가 암호화되어 다른 사용자가 읽을 수 없도록 추가 보안을 제공합니다.
  • ID 공급자는 인증에 성공했는지 여부를 나타내는 인증 상태를 반환합니다.
  • 성공하면 데이터 교환이 시작됩니다. 실패하면 사용자를 다시 인증해야 합니다.

단일 단계 인증

현재, 이 인증 방법은 서비스에서 가장 일반적으로 사용되는 방법입니다. 또한 유일한 인증 수단으로 사용되는 경우, 가장 안전한 형태의 인증이기도 합니다. 암호 복잡성 요구 사항, "비밀 질문" 및 정기적인 암호 변경으로 암호 사용이 더 안전해질 수 있지만, 사용자에게 더 많은 부담을 주므로 해커에 대한 효과적인 억제책이 아닙니다.

둘 이상의 요소가 있는 시스템보다 암호를 성공적으로 추측하는 것이 더 쉽다는 것이 암호의 문제입니다. 사용자 계정으로 데이터베이스를 도용하고 작은 웹 상점에서 암호를 해시한 경우, 다른 웹 사이트에서 사용되는 암호를 사용할 수 있습니다. 복잡한 암호는 기억하기 어렵기 때문에, 사용자는 항상 계정을 다시 사용하는 경향이 있습니다. IT 부서의 경우, 암호를 관리하면 재설정 메커니즘을 제공해야 하고 암호를 자주 업데이트해야 하며 안전한 방식으로 저장해야 하는 복잡성이 발생합니다.

모든 단점에 대해 단일 단계 인증은 사용자에게 자격 증명을 제어할 수 있게 해줍니다. 단일 단계 인증은 이를 만들고 수정하며 인증 프로세스에는 키보드만 필요합니다. 이는 단일 요소와 다단계 인증을 구분하는 기본 측면입니다.

2.1.1 웹 인증 브로커

앞에서 설명한 것처럼 IT 부서의 암호 인증과 관련된 문제 중 하나는 사용자 이름/암호, 재설정 메커니즘 등을 관리하는 오버헤드가 추가되는 것입니다. 점점 더 많이 사용되는 옵션은 인증에 대한 개방형 표준인 OAuth를 통해 인증을 제공하는 타사 ID 공급자를 사용하는 것입니다.

IT 부서는 OAuth를 사용하여 사용자 이름 및 암호를 사용하여 데이터베이스를 유지 관리하는 복잡성을 효과적으로 "아웃소싱"하고, 암호 기능 등을 Facebook, X 또는 Microsoft와 같은 타사 ID 공급자로 재설정할 수 있습니다.

사용자는 이러한 플랫폼에서 자신의 ID를 완전히 제어할 수 있지만, 앱은 사용자가 인증된 후 및 동의를 통해 공급자로부터 토큰을 요청할 수 있으며, 이를 사용하여 인증된 사용자에게 권한을 부여할 수 있습니다.

Windows의 웹 인증 브로커는 앱이 OAuth 및 OpenID와 같은 인증 및 권한 부여 프로토콜을 사용할 수 있는 API 및 인프라 집합을 제공합니다. 앱은 WebAuthenticationBroker API를 통해 인증 작업을 시작할 수 있으므로, WebAuthenticationResult가 반환됩니다. 다음의 그림에 통신 흐름에 대한 개요가 나와 있습니다.

wab 워크플로

앱은 브로커 역할을 하며, 앱에서 WebView를 통해 ID 공급자로 인증을 시작합니다. ID 공급자가 사용자를 인증하면, ID 공급자에서 사용자에 대한 정보를 요청하는 데 사용할 수 있는 토큰을 앱에 반환합니다. 보안 조치로서 ID 공급자를 사용하여 인증 프로세스를 조정하려면, 먼저 앱을 ID 공급자에 등록해야 합니다. 이 등록 단계는 공급자마다 다릅니다.

다음은 WebAuthenticationBroker API를 호출하여 공급자와 통신하는 일반적인 워크플로입니다.

  • ID 공급자에게 보내려는 요청 문자열을 생성합니다. 문자열 수와 각 문자열의 정보는 각 웹 서비스에 대해 다르지만, 일반적으로 URL을 포함하는 두 개의 URI 문자열을 포함합니다. 하나는 인증 요청이 전송되고, 다른 하나는 권한 부여가 완료된 후 사용자가 리디렉션됩니다.
  • WebAuthenticationBroker.AuthenticateAsync를 호출하여 요청 문자열을 전달하고 ID 공급자의 응답을 기다립니다.
  • WebAuthenticationResult.ResponseStatus를 호출하여 응답을 받을 때 상태를 가져옵니다.
  • 통신이 성공하면, ID 공급자가 반환한 응답 문자열을 처리합니다. 실패하면 오류를 처리합니다.

통신이 성공하면, ID 공급자가 반환한 응답 문자열을 처리합니다. 실패하면 오류를 처리합니다.

이 프로세스에 대한 샘플 C# 코드는 아래와 같습니다. 자세한 정보 및 연습은 WebAuthenticationBroker를 참조하세요. 전체 코드 샘플은 GitHub의 WebAuthenticationBroker 샘플을 확인하세요.

string startURL = "https://<providerendpoint>?client_id=<clientid>";
string endURL = "http://<AppEndPoint>";

var startURI = new System.Uri(startURL);
var endURI = new System.Uri(endURL);

try
{
    WebAuthenticationResult webAuthenticationResult = 
        await WebAuthenticationBroker.AuthenticateAsync( 
            WebAuthenticationOptions.None, startURI, endURI);

    switch (webAuthenticationResult.ResponseStatus)
    {
        case WebAuthenticationStatus.Success:
            // Successful authentication. 
            break;
        case WebAuthenticationStatus.ErrorHttp:
            // HTTP error. 
            break;
        default:
            // Other error.
        break;
    }
}
catch (Exception ex)
{
    // Authentication failed. Handle parameter, SSL/TLS, and
    // Network Unavailable errors here. 
}

2.2 다단계 인증

다단계 인증은 둘 이상의 인증 요소를 사용합니다. 일반적으로 암호와 같은 "당신이 아는 것"은 휴대 전화 또는 스마트 카드가 될 수 있는 "가지고 있는 것"과 결합됩니다. 공격자가 사용자의 암호를 검색하더라도, 장치 또는 카드 없이는 계정에 액세스할 수 없습니다. 장치나 카드가 손상된 경우에만 암호가 없는 공격자에게 유용하지 않습니다. 따라서 다단계 인증은 1단계 인증보다 더 안전하지만 더 복잡합니다.

다단계 인증을 사용하는 서비스는 종종 사용자에게 두 번째 자격 증명을 받는 방법을 선택할 수 있습니다. 이러한 유형의 인증의 예시는 SMS를 사용하여 인증 코드가 사용자의 휴대폰으로 전송되는 일반적으로 사용되는 프로세스입니다.

  • 사용자는 ID 공급자에게 사용자 이름과 암호를 제공합니다.
  • ID 공급자는 1단계 권한 부여에서와 같이 사용자 이름과 암호를 확인한 다음, 시스템에 저장된 사용자의 휴대폰 번호를 조회합니다.
  • 서버는 생성된 확인 코드가 포함된 SMS 메시지를 사용자의 휴대폰으로 보냅니다.
  • 사용자는 사용자에게 표시되는 양식을 통해 ID 공급자에게 확인 코드를 제공합니다.
  • ID 공급자는 두 자격 증명의 인증이 성공했는지 여부를 나타내는 인증 상태를 반환합니다.
  • 성공하면 데이터 교환이 시작됩니다. 그렇지 않으면 사용자를 다시 인증해야 합니다.

2단계 인증

이 프로세스는 사용자가 만들거나 제공하는 대신 두 번째 사용자 자격 증명이 사용자에게 전송된다는 점에서 단일 단계 인증과도 다릅니다. 따라서 사용자는 필요한 자격 증명을 완전히 제어할 수 없습니다. 이는 스마트 카드 두 번째 자격 증명으로 사용되는 경우에도 적용되며, 조직에서 사용자를 만들고 제공하는 일을 담당합니다.

2.2.1 Azure Active Directory

Azure AD(Azure Active Directory)는 단일 요소 또는 다단계 인증에서 ID 공급자 역할을 할 수 있는 클라우드 기반 ID 및 액세스 관리 서비스입니다. Azure AD 인증은 확인 코드와 함께 사용하거나 확인 코드 없이 사용할 수 있습니다.

Azure AD는 1단계 인증을 구현할 수도 있지만, 기업에서는 일반적으로 다단계 인증의 보안이 강화되어야 합니다. 다단계 인증 구성에서 Azure AD 계정으로 인증하는 사용자는 자신의 휴대폰 또는 Azure Authenticator 모바일 앱에 SMS 메시지로 확인 코드를 보낼 수 있습니다.

또한 Azure AD를 OAuth 공급자로 사용하여 표준 사용자에게 다양한 플랫폼의 앱에 대한 인증 및 권한 부여 메커니즘을 제공할 수 있습니다. 자세한 정보를 보려면 Azure Active Directory 및 Azure에서의 다단계 인증을 참조하세요.

2.4 Windows Hello

Windows에서는 운영 체제에 편리한 다단계 인증 메커니즘이 기본 제공됩니다. Windows Hello는 Windows에 기본 제공되는 새로운 생체 인식 로그인 시스템입니다. 운영 체제 안에서 함께 기본 제공되므로, Windows Hello를 사용하면 얼굴 또는 지문 식별을 통해 사용자 장치의 잠금을 해제할 수 있습니다. Windows 보안 자격 증명 저장소는 장치의 생체 데이터를 보호합니다.

Windows Hello는 장치가 개별 사용자를 인식할 수 있도록 탄탄한 방식을 제공하며, 이는 사용자와 요청된 서비스 및 데이터 간의 경로라는 그 첫 파트를 다룹니다. 장치가 사용자를 인식한 후 일지라도, 요청된 리소스에 대한 액세스 권한을 부여할지 여부를 결정하기 위해선 사용자 인증이 필요합니다. Windows Hello도 Windows에 완전히 통합된 강력한 2FA(2단계 인증)를 제공하며 재사용 가능한 암호를 특정 장치 및 생체 인식 제스처 또는 PIN의 조합으로 대체합니다. PIN은 Microsoft 계정 등록의 일부로 사용자가 지정합니다.

그러나 Windows Hello는 기존 2FA 시스템을 대체하는 데 그치는 것은 아닙니다. 이는 개념적으로 스마트 카드와 비슷합니다. 인증은 스트링 비교 대신 암호화 기본 형식을 사용하여 수행되며 사용자의 키 자료는 변조 방지 하드웨어 내에 안전하게 보관됩니다. Microsoft Hello는 스마트 카드 배포에 필요한 추가 인프라 구성 요소가 필요하지 않습니다. 특히 현재 인증서가 없는 경우, 인증서를 관리하기 위해 PKI(공개 키 인프라)를 필요로 하지 않습니다. Windows Hello는 가상 스마트 카드의 배포 유연성과 물리적 스마트 카드의 강력한 보안과 같은 스마트 카드 기술의 주요 장점만 가져오고 단점은 제외하였습니다.

사용자가 장치를 인증할 수 있으려면 먼저 Windows Hello에 장치를 등록해야 합니다. Windows Hello는 한 당사자가 퍼블릭 키를 사용하여 데이터를 암호화하면 다른 당사자는 프라이빗 키를 사용하여 해독할 수 있는 비대칭(퍼블릭/프라이빗 키) 암호화를 사용합니다. Windows Hello의 경우에는 퍼블릭/프라이빗 키 쌍 집합을 만들고 장치의 TPM(신뢰할 수 있는 플랫폼 모듈) 칩에 프라이빗 키를 씁니다. 장치가 등록되면 UWP 앱은 시스템 API를 호출하여 사용자의 공개 키를 검색할 수 있으며, 이 키는 서버에 사용자를 등록하는 데 사용할 수 있습니다.

앱의 등록 워크플로는 다음과 같을 수 있습니다.

windows hello 등록

수집한 등록 정보에는 이 간단한 시나리오보다 훨씬 더 많은 식별 정보가 포함될 수 있습니다. 예를 들어 앱이 은행업무 서비스와 같은 보안 서비스에 액세스하는 경우, 가입 프로세스의 일부로 신원 증명 및 기타 사항을 요청해야 합니다. 모든 조건이 충족되면 이 사용자의 공개 키가 백 엔드에 저장되고, 다음에 사용자가 서비스를 사용할 때 유효성 검사에 사용됩니다.

Windows Hello에 대한 자세한 내용은 비즈니스용 Windows Hello 개요 및 Windows Hello 개발자 가이드를 참조하세요.

3 전송 중인 데이터 보안 메서드

전송 중인 데이터 보안 메서드는 네트워크에 연결된 장치 간에 전송 중인 데이터에 적용됩니다. 데이터는 프라이빗 회사 인트라넷의 높은 보안 환경의 시스템 간 또는 웹의 비보안 환경에서 클라이언트와 웹 서비스 간에 전송될 수 있습니다. Windows 앱은 네트워킹 API를 통해 SSL과 같은 표준을 지원하고 개발자가 앱에 적절한 수준의 보안을 보장할 수 있는 Azure API Management와 같은 기술을 사용합니다.

3.1 원격 시스템 인증

원격 컴퓨터 시스템과 통신하는 두 가지 일반적인 시나리오가 있습니다.

  • 로컬 서버는 직접 연결을 통해 사용자를 인증합니다. 예를 들어, 서버와 클라이언트가 회사 인트라넷에 있는 경우입니다.
  • 웹 서비스는 인터넷을 통해 통신됩니다.

웹 서비스 통신에 대한 보안 요구 사항은 데이터가 더 이상 보안 네트워크의 일부일 뿐이 아니고 악의적인 공격자가 데이터를 가로채려는 가능성도 높기 때문에 직접 연결 시나리오보다 높습니다. 예를 들어, 다양한 형식의 장치가 서비스에 액세스하기 때문에 WCF와 달리 RESTful 서비스로 빌드될 가능성이 높습니다. 또한 이러한 서비스에 대한 인증 및 권한 부여는 새로운 과제를 발생시킵니다. 보안 원격 시스템 통신을 위한 두 가지 요구 사항에 대해 설명합니다.

첫 번째 요구 사항은 메시지 기밀성입니다. 클라이언트와 웹 서비스 간에 전달된 정보(예시: 사용자 ID 및 기타 개인 정보)는 전송 중에 제3자가 읽을 수 없어야 합니다. 이 작업은 일반적으로 메시지를 보내는 연결을 암호화하고 메시지 자체를 암호화하여 수행됩니다. 프라이빗/공개 키 암호화에서 공개 키는 누구나 사용할 수 있으며 특정 수신기로 보낼 메시지를 암호화하는 데 사용됩니다. 프라이빗 키는 수신기에서만 유지되며 메시지의 암호를 해독하는 데 사용됩니다.

두 번째 요구 사항은 메시지 무결성입니다. 클라이언트와 웹 서비스는 수신한 메시지가 상대방이 보내려는 메시지이고 전송 중에 메시지가 변경되지 않은지 확인할 수 있어야 합니다. 이 작업은 디지털 서명을 사용하여 메시지에 서명하고 인증서 인증을 사용하여 수행됩니다.

3.2 SSL 연결

클라이언트에 대한 보안 연결을 설정하고 유지하기 위해 웹 서비스는 HTTPS(Secure Hypertext Transfer Protocol)에서 지원하는 SSL(Secure Sockets Layer)을 사용할 수 있습니다. SSL은 공개 키 암호화와 서버 인증서를 지원하여 메시지 기밀성과 무결성을 제공합니다. SSL은 TLS(전송 계층 보안)로 대체되지만 TLS는 일반적으로 SSL이라고 합니다.

클라이언트가 서버의 리소스에 대한 액세스를 요청하면 SSL은 서버와의 협상 프로세스를 시작합니다. 이를 SSL 핸드셰이크라고 합니다. 암호화 수준, 공용 및 프라이빗 암호화 키 집합 및 클라이언트 및 서버 인증서의 ID 정보는 SSL 연결 기간 동안 모든 통신의 기초로 합의됩니다. 이때 서버에서 클라이언트를 인증해야 할 수도 있습니다. 연결이 설정되면, 모든 메시지는 연결이 닫히기 전까지 협상된 공개 키로 암호화됩니다.

3.2.1 SSL 고정

SSL은 암호화 및 인증서를 사용하여 메시지 기밀성을 제공할 수 있지만, 클라이언트가 통신하는 서버가 올바른 서버인지는 확인하지 않습니다. 권한 없는 타사에서 서버의 동작을 모방하여 클라이언트가 전송하는 중요한 데이터를 가로챌 수 있습니다. 이를 방지하기 위해, SSL 고정이라는 기술을 사용하여 서버의 인증서가 클라이언트가 기대하고 신뢰하는 인증서인지 확인합니다.

앱에서 SSL 고정을 구현하는 몇 가지 방법이 있으며, 각각 고유한 장단점이 있습니다. 가장 쉬운 방법은 앱의 패키지 매니페스트에서 인증서 선언을 사용하는 것입니다. 앱 패키지는 이 선언을 통해 디지털 인증서를 설치하고 단독 신뢰를 지정할 수 있습니다. 이로 인해 SSL 연결은 인증서 체인에 해당 인증서가 있는 앱과 서버 간에만 허용됩니다. 또한 이 메커니즘을 사용하면 신뢰할 수 있는 공용 인증 기관에 대한 타사 종속성이 필요 없으므로, 자체 서명된 인증서를 안전하게 사용할 수 있습니다.

ssl 매니페스트

유효성 검사 논리에 대한 더 많은 제어를 위해 API를 사용하여 HTTPS 요청에 대한 응답으로 서버에서 반환된 인증서의 유효성을 검사할 수 있습니다. 이 메서드는 요청을 보내고 응답을 검사해야 하므로, 실제로 요청에 중요한 정보를 보내기 전에 유효성 검사로 추가해야 합니다.

다음의 C# 코드는 이 SSL 고정의 메서드를 보여 줍니다. ValidateSSLRoot 메서드는 HTTP 요청을 실행하기 위해 HttpClient 클래스를 사용합니다. 클라이언트가 응답을 보낸 뒤, 이는 RequestMessage.TransportInformation.ServerIntermediateCertificates 컬렉션을 사용하여 서버에서 반환된 인증서를 검사합니다. 그런 다음 클라이언트는 포함된 지문을 사용하여 전체 인증서 체인의 유효성을 검사할 수 있습니다. 이 방법을 사용하려면, 서버 인증서가 만료되고 갱신될 때 앱에서 인증서 지문을 업데이트해야 합니다.

private async Task ValidateSSLRoot()
{
    // Send a get request to Bing
    var httpClient = new HttpClient();
    var bingUri = new Uri("https://www.bing.com");
    HttpResponseMessage response = 
        await httpClient.GetAsync(bingUri);

    // Get the list of certificates that were used to
    // validate the server's identity
    IReadOnlyList<Certificate> serverCertificates = response.RequestMessage.TransportInformation.ServerIntermediateCertificates;
  
    // Perform validation
    if (!ValidateCertificates(serverCertificates))
    {
        // Close connection as chain is not valid
        return;
    }
    // Validation passed, continue with connection to service
}

private bool ValidateCertificates(IReadOnlyList<Certificate> certs)
{
    // In this example, we iterate through the certificates
    // and check that the chain contains
    // one specific certificate we are expecting
    foreach (var cert in certs)
    {
        byte[] thumbprint = cert.GetHashValue();

        // Check if the thumbprint matches whatever you 
        // are expecting
        var expected = new byte[] { 212, 222, 32, 208, 94, 102, 
            252, 83, 254, 26, 80, 136, 44, 120, 219, 40, 82, 202, 
            228, 116 };

        // ThumbprintMatches does the byte[] comparison 
        if (ThumbprintMatches(thumbprint, expected))
        {
            return true;
        }
    }
    return false;
}

3.3 REST API에 대한 액세스 게시 및 보안

웹 서비스에 대한 권한 있는 액세스를 보장하려면, API 호출이 수행될 때마다 인증이 필요합니다. 성능과 규모를 제어할 수 있다는 것은 웹 서비스가 웹에 노출될 때 고려해야 할 사항이기도 합니다. Azure API Management는 세 가지 수준에서 기능을 제공하는 동시에 웹에서 API를 노출하는 데 도움이 되는 서비스입니다.

API의 게시자/관리자는 Azure API Management의 게시자 포털을 통해 API를 쉽게 구성할 수 있습니다. 여기서 API 집합을 만들 수 있으며, API에 대한 액세스 권한을 가진 사용자를 제어할 수 있습니다.

이러한 API에 액세스하려는 개발자는 개발자 포털을 통해 즉시 액세스를 제공하거나 게시자/관리자의 승인을 요구할 수 있는 요청을 수행할 수 있습니다. 개발자는 웹 서비스에서 제공하는 API를 신속하게 채택하기 위해 개발자 포털에서 API 설명서 및 샘플 코드를 확인할 수 있습니다.

이러한 개발자가 만든 앱은 Azure API Management에서 제공하는 프록시를 통해 API에 액세스합니다. 프록시는 둘 다 무명 계층을 제공하여 게시자/관리자 서버에서 API의 실제 엔드포인트를 숨기고 API 변환과 같은 추가 논리를 포함할 수 있으므로, 한 API에 대한 호출이 다른 API로 리디렉션될 때 노출된 API가 일관되게 유지되도록 할 수 있습니다. 특정 IP 도메인 또는 도메인 집합에서 발생하는 API 호출을 IP 필터링을 사용하여 차단할 수도 있습니다. 또한 Azure API Management는 각 API 호출을 인증하고 권한을 부여하기 위해 API 키라는 공개 키 집합을 사용하여 웹 서비스를 안전하게 유지합니다. 권한 부여가 실패하면, API 및 API에서 지원하는 기능에 대한 액세스는 차단됩니다.

Azure API Management는 웹 서비스의 성능을 최적화하기 위해 서비스(제한이라고 불리는 절차)에 대한 API 호출 수를 줄일 수도 있습니다. 자세히 알아보려면, AzureCon 2015에서 Azure API 관리 및 Azure API 관리를 검토하세요.

4 미사용 데이터 보안 메서드

데이터가 장치에 도착할 때, 해당 데이터를 “미사용 데이터”라고 합니다. 이 데이터는 권한이 없는 사용자 또는 앱이 액세스할 수 없도록 안전한 방법으로 장치에 저장해야 합니다. Windows의 앱 모델은 필요한 경우 데이터를 공유하는 API를 제공하면서 모든 앱에서 저장된 데이터에만 액세스할 수 있도록 많은 작업을 수행합니다. 또한 데이터를 암호화하고 자격 증명을 안전하게 저장할 수 있도록 추가 API를 사용할 수 있습니다.

4.1 Windows 앱 모델

일반적으로 Windows는 앱에 대한 정의를 가진 적이 없습니다. 가장 일반적으로 실행 파일(.exe)이라고 하며 설치, 상태 스토리지, 실행 길이, 버전 관리, OS 통합 또는 앱 간 통신은 포함되지 않았습니다. Universal Windows Platform 모델은 설치, 런타임 환경, 리소스 관리, 업데이트, 데이터 모델 및 제거를 포함하는 앱 모델을 정의합니다.

Windows 10 앱은 컨테이너에서 실행되므로, 기본적으로 제한된 권한이 있습니다(사용자가 추가 권한을 요청하고 부여할 수 있음). 예를 들어 앱이 시스템의 파일에 액세스하려는 경우, Windows.Storage.Pickers 네임스페이스에서 파일 선택기를 사용하여 사용자가 파일을 선택할 수 있도록 해야 합니다(파일에 대한 직접 액세스는 사용하도록 설정되지 않음). 또 다른 예시는 앱이 사용자의 위치 데이터에 액세스하려는 경우, 위치 디바이스 기능을 선언해야 하므로 다운로드 시 사용자에게 이 앱이 사용자의 위치에 대한 액세스를 요청하라는 메시지를 표시한다는 것입니다. 또한 앱이 사용자의 위치에 처음으로 액세스하려고 할 때, 사용자에게 추가 동의 프롬프트가 표시되어 데이터에 액세스할 수 있는 권한을 요청합니다.

이 앱 모델은 앱에 대한 "감옥"으로 작동합니다. 즉, 닿을 수 없지만 외부에서 연결할 수 없는 "성"은 아닙니다(관리자 권한이 있는 애플리케이션은 여전히 연결할 수 있음). 조직/IT에서 실행할 수 있는(Win32) 앱을 지정할 수 있는 Windows의 Device Guard는 이 액세스를 제한하는 데 도움이 될 수 있습니다.

또한 앱 모델은 앱 수명 주기를 관리합니다. 예를 들어, 이는 기본적으로 앱의 백그라운드 실행을 제한합니다. 앱이 백그라운드로 들어가면 (코드에서 앱 일시 중단을 해결하기 위해 앱에 짧은 기간을 부여한 후) 프로세스가 일시 중단되고 메모리가 고정됩니다. 운영 체제는 앱이 특정 백그라운드 작업 실행을 요청하는 메커니즘을 제공합니다(일정에 따라 인터넷/Bluetooth 연결, 전원 변경 등과 같은 다양한 이벤트 및 음악 재생 또는 GPS 추적과 같은 특정 시나리오에서 트리거됨).

장치의 메모리 리소스가 부족하면, Windows는 앱을 종료하여 메모리 공간을 확보합니다. 이 수명 주기 모델은 앱이 일시 중단될 때마다 데이터를 유지하도록 강제합니다. 이는 일시 중단과 종료 사이에 사용 가능한 추가 시간이 없기 때문입니다.

자세한 정보를 보려면 It's Universal: (Windows 10/11 애플리케이션의 수명 주기 이해하기를 참조하세요.

4.2 저장된 자격 증명 보호

인증된 서비스에 액세스하는 Windows 앱은 종종 사용자에게 로컬 디바이스에 자격 증명을 저장하는 옵션을 제공합니다. 이는 사용자의 편의를 위한 것이므로, 사용자 이름 및 암호를 제공하면 앱은 이후 앱 시작 시 자동으로 사용합니다. 공격자가 이 저장된 데이터에 액세스하는 경우 보안 문제가 될 수 있으므로 Windows는 패키지된 앱이 보안 자격 증명 보관에 사용자 자격 증명을 저장하는 기능을 제공합니다. 앱은 자격 증명을 앱의 스토리지 컨테이너에 저장하는 대신 보관에서 자격 증명을 저장하고 검색하기 위해 자격 증명 보관 API를 호출합니다. 자격 증명 보관은 운영 체제에서 관리하지만, 액세스는 이를 저장하는 앱으로 제한되어 자격 증명 스토리지에 대해 안전하게 관리되는 솔루션을 제공합니다.

사용자가 저장할 자격 증명을 제공하면 앱은 Windows.Security.Credentials 네임스페이스의 PasswordVault 개체를 사용하여 자격 증명 보관에 대한 참조를 가져옵니다. 그런 다음 Windows 앱의 식별자와 사용자 이름 및 암호를 포함하는 PasswordCredential 개체를 만듭니다. 이는 자격 증명을 사물함에 저장하기 위해 PasswordVault.Add 메서드에 전달됩니다. 다음의 C# 코드 예시는 이를 수행하는 방법을 보여 줍니다.

var vault = new PasswordVault();
vault.Add(new PasswordCredential("My App", username, password));

다음의 C# 코드 예시에서 앱은 앱에 해당하는 모든 자격 증명을 요청하기 위해 PasswordVault 개체의 FindAllByResource 메서드를 호출합니다. 둘 이상이 반환되면, 사용자 이름을 입력하라는 메시지가 사용자에게 표시됩니다. 자격 증명이 사물함에 없으면, 앱에서 사용자에게 자격 증명을 묻는 메시지를 표시합니다. 그러면 사용자가 자격 증명을 사용하여 서버에 로그인합니다.

private string resourceName = "My App";
private string defaultUserName;

private void Login()
{
    PasswordCredential loginCredential = GetCredentialFromLocker();

    if (loginCredential != null)
    {
        // There is a credential stored in the locker.
        // Populate the Password property of the credential
        // for automatic login.
        loginCredential.RetrievePassword();
    }
    else
    {
        // There is no credential stored in the locker.
        // Display UI to get user credentials.
        loginCredential = GetLoginCredentialUI();
    }
    // Log the user in.
    ServerLogin(loginCredential.UserName, loginCredential.Password);
}

private PasswordCredential GetCredentialFromLocker()
{
    PasswordCredential credential = null;

    var vault = new PasswordVault();

    IReadOnlyList<PasswordCredential> credentialList = null;

    try
    {
        credentialList = vault.FindAllByResource(resourceName);
    }
    catch(Exception)
    {
        return null;
    }

    if (credentialList.Count == 1)
    {
        credential = credentialList[0];
    }
    else if (credentialList.Count > 0)
    {
        // When there are multiple usernames,
        // retrieve the default username. If one doesn't
        // exist, then display UI to have the user select
        // a default username.
        defaultUserName = GetDefaultUserNameUI();

        credential = vault.Retrieve(resourceName, defaultUserName);
    }
    return credential;
}

자세한 정보를 보려면 자격 증명 보관을 참조하세요.

4.3 저장된 데이터 보호

일반적으로 미사용 데이터라고 불리는 저장 데이터를 처리하는 경우, 암호화하면 권한이 없는 사용자가 저장된 데이터에 액세스하지 못하게 할 수 있습니다. 데이터를 암호화하기 위한 두 가지 일반적인 메커니즘은 대칭 키를 사용하거나 비대칭 키를 사용하는 것입니다. 하지만 데이터 암호화는 데이터가 전송된 시간과 저장된 시간 사이에 변경되지 않도록 보장할 수 없습니다. 다른 말로 하면, 데이터 무결성을 보장할 수 없습니다. 메시지 인증 코드, 해시 및 디지털 서명을 사용하는 것은 이 문제를 해결하는 일반적인 기술입니다.

4.3.1 데이터 암호화

대칭 암호화를 사용하면 보낸 사람과 받는 사람 모두 동일한 키를 가지며, 이를 데이터를 암호화하고 암호 해독하는 데 사용합니다. 이 접근 방식에서 어려운 점은 두 당사자가 이를 인식할 수 있도록 키를 안전하게 공유하는 것입니다.

이에 대한 한 가지 해답은 퍼블릭/프라이빗 키 쌍이 사용되는 비대칭 암호화입니다. 퍼블릭 키는 메시지를 암호화하려는 모든 사용자와 자유롭게 공유됩니다. 프라이빗 키는 항상 비밀로 유지되므로 사용자만 데이터를 해독하는 데 사용할 수 있습니다. 퍼블릭 키의 검색을 허용하는 일반적인 기술은 단순히 인증서라고도 하는 디지털 인증서를 사용하는 것입니다. 인증서는 이름, 발급자, 전자 메일 주소 및 국가와 같은 사용자 또는 서버에 대한 정보 외에도 퍼블릭 키에 대한 정보를 보유합니다.

Windows 앱 개발자는 SymmetricKeyAlgorithmProvider 및 AsymmetricKeyAlgorithmProvider 클래스를 사용하여 UWP 앱에서 대칭 및 비대칭 암호화를 구현할 수 있습니다. 또한 CryptographicEngine 클래스를 사용하여 데이터를 암호화 및 암호 해독하고, 콘텐츠에 서명하고, 디지털 서명을 확인할 수 있습니다. 또한 앱은 저장된 로컬 데이터를 암호화하고 암호를 해독하기 위해 Windows.Security.Cryptography.DataProtection 네임스페이스의 DataProtectionProvider 클래스를 사용할 수 있습니다.

4.3.2 메시지 변조 감지하기(MAC, 해시 및 서명)

MAC은 MAC 암호화 알고리즘에 대한 입력으로 대칭 키(비밀 키라고 함) 또는 메시지를 사용하여 발생하는 코드(또는 태그)입니다. 비밀 키와 알고리즘은 메시지를 전송하기 전에 보낸 사람 및 수신자에 의해 동의됩니다.

MAC는 이와 같은 메시지를 확인합니다.

  • 발신자는 비밀 키를 MAC 알고리즘에 대한 입력으로 사용하여 MAC 태그를 파생합니다.
  • 발신자는 MAC 태그 및 메시지를 받는 사람에게 보냅니다.
  • 수신자는 비밀 키와 메시지를 MAC 알고리즘에 대한 입력으로 사용하여 MAC 태그를 파생합니다.
  • 수신자는 MAC 태그를 보낸 사람의 MAC 태그와 비교합니다. 동일한 경우, 메시지가 변조되지 않았다는 것을 알 수 있습니다.

mac 확인

Windows 앱은 MacAlgorithmProvider 클래스를 호출하여 MAC 암호화 알고리즘을 수행하기 위한 키 및 CryptographicEngine 클래스를 생성하여 MAC 메시지 확인을 구현할 수 있습니다.

4.3.3 해시 사용하기

해시 함수는 임의로 긴 데이터 블록을 사용하고, 해시 값이라는 고정 크기 비트 문자열을 반환하는 암호화 알고리즘입니다. 이를 수행할 수 있는 해시 함수의 전체 제품군이 있습니다.

위의 메시지 전송 시나리오에서 해시 값을 MAC 대신 사용할 수 있습니다. 보낸 사람은 해시 값과 메시지를 보내고, 받는 사람은 보낸 사람의 해시 값과 메시지에서 자신의 해시 값을 파생시키고 두 해시 값을 비교합니다. Windows에서 실행되는 앱은 HashAlgorithmProvider 클래스를 호출하여 사용 가능한 해시 알고리즘을 열거하고 그 중 하나를 실행할 수 있습니다. CryptographicHash 클래스는 해시 값을 나타냅니다. CryptographicHash.GetValueAndReset 메서드는 사용할 때마다 개체를 다시 만들지 않고도 다른 데이터를 반복적으로 해시하는 데 사용할 수 있습니다. CryptographicHash 클래스의 Append 메서드는 해시할 버퍼에 새 데이터를 추가합니다. 이 전체 프로세스는 다음의 C# 코드 예시에 나와 있습니다.

public void SampleReusableHash()
{
    // Create a string that contains the name of the
    // hashing algorithm to use.
    string strAlgName = HashAlgorithmNames.Sha512;

    // Create a HashAlgorithmProvider object.
    HashAlgorithmProvider objAlgProv = HashAlgorithmProvider.OpenAlgorithm(strAlgName);

    // Create a CryptographicHash object. This object can be reused to continually
    // hash new messages.
    CryptographicHash objHash = objAlgProv.CreateHash();

    // Hash message 1.
    string strMsg1 = "This is message 1";
    IBuffer buffMsg1 = CryptographicBuffer.ConvertStringToBinary(strMsg1, BinaryStringEncoding.Utf16BE);
    objHash.Append(buffMsg1);
    IBuffer buffHash1 = objHash.GetValueAndReset();

    // Hash message 2.
    string strMsg2 = "This is message 2";
    IBuffer buffMsg2 = CryptographicBuffer.ConvertStringToBinary(strMsg2, BinaryStringEncoding.Utf16BE);
    objHash.Append(buffMsg2);
    IBuffer buffHash2 = objHash.GetValueAndReset();

    // Convert the hashes to string values (for display);
    string strHash1 = CryptographicBuffer.EncodeToBase64String(buffHash1);
    string strHash2 = CryptographicBuffer.EncodeToBase64String(buffHash2);
}

4.3.4 디지털 서명

디지털 서명된 저장된 메시지의 데이터 무결성은 MAC 인증과 유사한 방식으로 확인됩니다. 디지털 서명 워크플로가 작동하는 방식은 다음과 같습니다.

  • 보낸 사람은 해시 알고리즘에 대한 입력으로 메시지를 사용하여 해시 값(다이제스트라고도 함)을 파생합니다.
  • 보낸 사람은 프라이빗 키를 사용하여 다이제스트를 암호화합니다.
  • 보낸 사람은 메시지, 암호화된 다이제스트 및 사용된 해시 알고리즘의 이름을 보냅니다.
  • 받은 사람은 퍼블릭 키를 사용하여 수신한 암호화된 다이제스트의 암호를 해독합니다. 그런 다음 해시 알고리즘을 사용하여 메시지를 해시하여 자체 다이제스트를 만듭니다. 그리고 마지막으로 받는 사람은 두 다이제스트(수신 및 암호 해독된 다이제스트와 다이제스트가 만든 다이제스트)를 비교합니다. 두 일치 항목이 받는 사람이 프라이빗 키의 소유자에 의해 메시지를 보냈는지 확인할 수 있는 경우에만 해당 메시지가 자신이 누구인지, 그리고 전송 중에 메시지가 변경되지 않았는지 확인할 수 있습니다.

디지털 서명

해시 알고리즘은 매우 빠르므로, 해시 값은 큰 메시지에서도 빠르게 파생될 수 있습니다. 결과 해시 값은 임의의 길이이며 전체 메시지보다 짧을 수 있으므로, 퍼블릭 및 프라이빗 키를 사용하여 전체 메시지가 아닌 다이제스트만 암호화하고 암호 해독하는 것은 최적화입니다.

자세한 정보를 보려면 디지털 서명, MAC, 해시 및 서명 및 암호화에 대한 문서를 참조하세요.

5 요약

Windows의 유니버설 Windows 플랫폼 운영 체제 기능을 활용하여 보다 안전한 앱을 만드는 다양한 방법을 제공합니다. OAuth ID 공급자를 사용한 단일 요소, 다단계 또는 조정된 인증과 같은 다양한 인증 시나리오에서 API는 인증과 관련된 가장 일반적인 문제를 완화하기 위해 존재합니다. Windows Hello는 사용자를 인식하고 식별 회피 시도를 자동으로 무효화시키는 새로운 생체 인식 로그인 시스템을 제공합니다. 또한 신뢰할 수 있는 플랫폼 모듈 외부에서 표시 또는 사용할 수 없는 여러 계층의 키와 인증서를 제공합니다. 더하여, 입증 신원 키 및 인증서의 선택적 사용을 통해 추가 보안 보호막을 제공합니다.

전송 중인 데이터를 보호하기 위해, API는 SSL을 통해 원격 시스템과 안전하게 통신하는 동시에 SSL 고정을 사용하여 서버의 신뢰성을 확인할 수 있는 가능성을 제공합니다. API를 안전하고 제어된 방식으로 게시하는 것은 API 엔드포인트의 추가 난독화를 제공하는 프록시를 사용하여 웹에서 API를 노출하기 위한 강력한 구성 옵션을 제공하여 Azure API Management가 지원하는 기능입니다. 이러한 API에 대한 액세스는 API 키를 사용하여 보호되며, API 호출을 제한하여 성능을 제어할 수 있습니다.

장치에 데이터가 도착하면 Windows 앱 모델은 권한이 없는 방식으로 다른 앱의 데이터에 액세스하지 못하게 하면서 앱이 설치, 업데이트 및 액세스하는 방법을 보다 세세하게 제어합니다. 자격 증명 보관은 운영 체제에서 관리하는 사용자 자격 증명의 보안 스토리지를 제공할 수 있으며, Universal Windows Platform에 의해 제공되는 암호화 및 해시 API를 사용하여 장치에서 다른 데이터를 보호할 수 있습니다.

6 리소스

6.1 방법 문서

6.2 코드 샘플

6.3 API 참조