보안 Windows 앱 개발 소개Intro to secure Windows app development

이 소개 문서를 통해 앱 설계자와 개발자는 UWP (secure 유니버설 Windows 플랫폼) 앱을 빠르게 만들 수 있는 다양 한 Windows 10 플랫폼 기능을 보다 잘 이해할 수 있습니다.This introductory article helps app architects and developers better understand the various Windows 10 platform capabilities that accelerate creating secure Universal Windows Platform (UWP) apps. 인증, 데이터 처리 및 미사용 데이터의 각 단계에서 사용할 수 있는 Windows 보안 기능을 사용 하는 방법에 대해 자세히 설명 합니다.It details how to use the Windows security features available at each of the following stages: authentication, data-in-flight, and data-at-rest. 각 항목에 포함 된 추가 리소스를 검토 하 여 각 항목에 대 한 자세한 정보를 찾을 수 있습니다.You can find more in-depth information on each topic by reviewing the additional resources included in each chapter.

1 소개1 Introduction

보안 앱을 개발 하는 것은 어려울 수 있습니다.Developing a secure app can be a challenge. 오늘날의 기동성이 뛰어난 모바일, 소셜, 클라우드 및 복잡 한 엔터프라이즈 앱 환경에서 고객은 앱을 사용 가능 하 게 하 고 그 어느 때 보다 빠르게 업데이트할 것을 요구 합니다.In today’s fast-paced world of mobile, social, cloud, and complex enterprise apps, customers expect apps to become available and updated faster than ever. 또한 다양 한 유형의 장치를 사용 하 여 앱 환경을 만드는 복잡성에 추가 합니다.They also use many types of devices, further adding to the complexity of creating app experiences. UWP (Windows 10 유니버설 Windows 플랫폼) 용으로 빌드하는 경우 데스크톱, 랩톱, 태블릿 및 모바일 장치의 기존 목록이 포함 될 수 있습니다. 사물 인터넷, Xbox One, Microsoft Surface Hub 및 HoloLens를 확장 하는 새 장치 목록에 추가 합니다.If you build for the Windows 10 Universal Windows Platform (UWP), that could include the traditional list of desktops, laptops, tablets, and mobile devices; in addition to a growing list of new devices spanning the Internet of Things, Xbox One, Microsoft Surface Hub, and HoloLens. 개발자는 앱이 관련 된 모든 플랫폼 또는 장치에서 데이터를 안전 하 게 통신 하 고 저장 하도록 해야 합니다.As the developer, you must ensure your apps communicate and store data securely, across all the platforms or devices involved.

Windows 10 보안 기능을 활용 하는 경우의 몇 가지 이점은 다음과 같습니다.Here are some of the benefits of utilizing Windows 10 security features.

  • 보안 구성 요소 및 기술에 일관 된 Api를 사용 하 여 Windows 10을 지 원하는 모든 장치에서 표준화 된 보안을 사용할 수 있습니다.You will have standardized security across all devices that support Windows 10, by using consistent APIs for security components and technologies.
  • 이러한 보안 시나리오를 포함 하는 사용자 지정 코드를 구현 하는 경우 보다 더 작은 코드를 작성, 테스트 및 유지 관리 합니다.You write, test, and maintain less code than you would if you implemented custom code to cover these security scenarios.
  • 운영 체제를 사용 하 여 앱에서 해당 리소스 및 로컬 또는 원격 시스템 리소스에 액세스 하는 방법을 제어 하기 때문에 앱은 안정적이 고 안전 하 게 유지 됩니다.Your apps become more stable and secure because you use the operating system to control how the app accesses its resources and local or remote system resources.

인증 하는 동안 특정 서비스에 대 한 액세스를 요청 하는 사용자의 id가 확인 됩니다.During authentication, the identity of a user requesting access to a particular service is validated. Windows Hello는 windows 앱에서 보다 안전한 인증 메커니즘을 만드는 데 도움이 되는 Windows 10의 구성 요소입니다.Windows Hello is the component in Windows 10 that helps create a more secure authentication mechanism in Windows apps. 이 기능을 사용 하면 사용자의 지문, 얼굴 또는 조리개와 같은 개인 식별 번호 (PIN) 또는 생체 인식을 사용 하 여 앱에 대 한 multi-factor authentication을 구현할 수 있습니다.With it, you can use a Personal Identification Number (PIN) or biometrics such as the user’s fingerprints, face, or iris to implement multi-factor authentication for your apps.

비행 데이터는 연결 및 연결을 통해 전송 되는 메시지를 나타냅니다.Data-in-flight refers to the connection and the messages transferred across it. 이에 대 한 예는 웹 서비스를 사용 하 여 원격 서버에서 데이터를 검색 하는 것입니다.An example of this is retrieving data from a remote server using web services. SSL(Secure Sockets Layer) (SSL) 및 보안 하이퍼텍스트 전송 프로토콜 (HTTPS)을 사용 하면 연결의 보안이 보장 됩니다.The use of Secure Sockets Layer (SSL) and Secure Hypertext Transfer Protocol (HTTPS) ensures the security of the connection. 중간 파티가 이러한 메시지에 액세스 하거나 권한이 없는 앱이 웹 서비스와 통신 하지 못하도록 하는 것은 비행 중인 데이터를 보호 하기 위한 핵심입니다.Preventing intermediary parties from accessing these messages, or unauthorized apps from communicating with the web services, is key to securing data in flight.

마지막으로, 미사용 데이터는 메모리 또는 저장소 미디어에 있는 데이터와 관련이 있습니다.Lastly, data-at-rest relates to data residing in memory or on storage media. Windows 10에는 앱 간의 무단 데이터 액세스를 방지 하는 앱 모델이 있으며, 암호화 Api를 제공 하 여 장치의 데이터를 더욱 안전 하 게 보호 합니다.Windows 10 has an app model that prevents unauthorized data access between apps, and offers encryption APIs to further secure data on the device. 자격 증명 보관 이라는 기능을 사용 하 여 장치에 사용자 자격 증명을 안전 하 게 저장 하 고, 운영 체제에서 다른 앱이 액세스할 수 없도록 할 수 있습니다.A feature called Credential Locker can be used to securely store user credentials on the device, with the operating system preventing other apps from accessing them.

2 인증 요소2 Authentication Factors

데이터를 보호 하려면 해당 데이터에 대 한 액세스를 요청 하는 사용자를 식별 하 고 요청 하는 데이터 리소스에 액세스할 수 있도록 권한을 부여 해야 합니다.To protect data, the person requesting access to it must be identified and authorized to access the data resources they request. 사용자를 식별 하는 프로세스를 인증 이라고 하 고 리소스에 대 한 액세스 권한을 결정 하는 것을 권한 부여 라고 합니다.The process of identifying a user is called authentication, and determining access privileges to a resource is called authorization. 이러한 작업은 밀접 하 게 관련 된 작업 이며, 사용자는 구별할 수 없습니다.These are closely related operations, and to the user they might be indistinguishable. 이러한 작업은 여러 가지 요인에 따라 비교적 단순 하거나 복잡 한 작업 일 수 있습니다. 예를 들어 데이터가 하나의 서버에 있는지 또는 여러 시스템에 분산 되어 있는지 여부입니다.They can be relatively simple or complex operations, depending on many factors: for example, whether the data resides on one server or is distributed across many systems. 인증 및 권한 부여 서비스를 제공 하는 서버를 id 공급자 라고 합니다.The server providing the authentication and authorization services is referred to as the identity provider.

사용자는 특정 서비스 및/또는 앱을 사용 하 여 자신을 인증 하기 위해 사용자가 알고 있는 자격 증명, 보유 한 항목 및/또는 다른 항목을 사용 하 여 자격 증명을 사용 합니다.To authenticate themselves with a particular service and/or app, the user employs credentials made up of something they know, something they have, and/or something they are. 이러한 각을 인증 요소 라고 합니다.Each of these are called authentication factors.

  • 사용자가 알고 있는 것은 일반적으로 암호 이지만 개인 식별 번호 (PIN) 또는 "비밀" 질문 및 답변 쌍 일 수도 있습니다.Something the user knows is usually a password, but it can also be a personal identification number (PIN) or a “secret” question-and-answer pair.
  • 사용자 가 가장 자주 사용 되는 것은 사용자에 게 고유한 인증 데이터를 포함 하는 USB 스틱과 같은 하드웨어 메모리 장치입니다.Something the user has is most often a hardware memory device such as a USB stick containing the authentication data unique to the user.
  • 사용자는 종종 사용자 의 지문을 포함 하지만 사용자의 음성, 얼굴, ocular (눈) 특성, 동작 패턴 등 널리 사용 되는 요소가 있습니다.Something the user is often encompasses their fingerprints, but there are increasingly popular factors like the user’s speech, facial, ocular (eye) characteristics, or patterns of behavior. 데이터를 데이터로 저장 하는 경우 이러한 측정을 생체 인식 이라고 합니다.When stored as data, these measurements are called biometrics.

사용자가 만든 암호는 자체의 인증 요소 이지만 종종 충분 하지 않습니다. 암호를 알고 있는 사용자는 해당 암호를 소유 하는 사용자를 가장할 수 있습니다.A password created by the user is an authentication factor in itself, but it often isn’t sufficient; anyone who knows the password can impersonate the user who owns it. 스마트 카드는 더 높은 수준의 보안을 제공할 수 있지만 도난당 하거나, 손실 되거나, 위치가 잘못 되었을 수 있습니다.A smart card can provide a higher level of security, but it might be stolen, lost, or misplaced. 사용자가 지문을 사용 하 여 또는 ocular 검색을 통해 사용자를 인증할 수 있는 시스템은 가장 높은 수준의 보안을 제공할 수 있지만, 모든 사용자가 사용 하지 못할 수도 있는 고가의 특수 하드웨어 (예: 얼굴 인식을 위한 Intel RealSense 카메라)가 필요 합니다.A system that can authenticate a user by their fingerprint or by an ocular scan might provide the highest and most convenient level of security, but it requires expensive and specialized hardware (for example, an Intel RealSense camera for facial recognition) that might not be available to all users.

시스템에서 사용 하는 인증 방법 디자인은 데이터 보안의 복잡 하 고 중요 한 측면입니다.Designing the method of authentication used by a system is a complex and important aspect of data security. 일반적으로 인증에 사용 하는 요소 수가 많을 수록 시스템이 더 안전 하 게 보호 됩니다.In general, the greater number of factors you use in authentication, the more secure the system is. 동시에 인증을 사용할 수 있어야 합니다.At the same time, authentication must be usable. 일반적으로 사용자가 하루에 여러 번 로그인 하므로 프로세스가 빨라야 합니다.A user will usually log in many times a day, so the process must be fast. 인증 유형을 선택 하는 것은 보안과 사용 편의성을 절충 하는 것입니다. 단일 단계 인증은 가장 안전 하 고 사용 하기 쉽고, multi-factor authentication은 더 안전 하지만 더 많은 요인이 추가 됨에 따라 더 복잡 하 게 됩니다.Your choice of authentication type is a trade-off between security and ease of use; single-factor authentication is the least secure and easiest to use, and multi-factor authentication becomes more secure, but more complex as more factors are added.

2.1 단일 단계 인증2.1 Single-factor authentication

이 인증 형태는 단일 사용자 자격 증명을 기반으로 합니다.This form of authentication is based on a single user credential. 일반적으로 암호 이지만 PIN (개인 식별 번호) 일 수도 있습니다.This is usually a password, but it could also be a personal identification number (PIN).

단일 단계 인증 프로세스는 다음과 같습니다.Here’s the process of single-factor authentication.

  • 사용자가 id 공급자에 대 한 사용자 이름과 암호를 제공 합니다.The user provides their username and password to the identity provider. Id 공급자는 사용자의 id를 확인 하는 서버 프로세스입니다.The identity provider is the server process that verifies the identity of the user.
  • ID 공급자가 사용자 이름 및 암호가 시스템에 저장된 것과 동일한지 확인합니다.The identity provider checks whether the username and password are the same as those stored in the system. 대부분의 경우 암호는 암호화 되어 다른 사용자가 읽을 수 없도록 추가 보안이 제공 됩니다.In most cases, the password will be encrypted, providing additional security so that others cannot read it.
  • Id 공급자는 인증의 성공 여부를 나타내는 인증 상태를 반환 합니다.The identity provider returns an authentication status that indicates whether the authentication was successful.
  • 성공 하면 데이터 교환이 시작 됩니다.If successful, data exchange begins. 실패 한 경우 사용자를 다시 인증 해야 합니다.If unsuccessful, the user must be re-authenticated.

단일 단계 인증

현재이 인증 방법은 서비스에서 가장 일반적으로 사용 되는 것입니다.Today, this method of authentication is the most commonly used one across services. 인증의 유일한 수단으로 사용 되는 경우 가장 안전 하지 않은 인증 형식 이기도 합니다.It is also the least secure form of authentication when used as the only means of authentication. 암호 복잡성 요구 사항, "본인 확인 질문" 및 일반 암호 변경으로 인해 암호를 보다 안전 하 게 사용할 수 있지만 사용자에 게 더 많은 부담을 주는 것은 해커에 게 효과적인 deterrent 아닙니다.Password complexity requirements, "secret questions," and regular password changes can make using passwords more secure, but they put more burden on users and they’re not an effective deterrent against hackers.

암호를 사용 하는 경우 두 개 이상의 요인이 있는 시스템 보다 성공적으로 추측 하는 것이 더 쉬울 수 있습니다.The challenge with passwords is that it is easier to guess them successfully than systems that have more than one factor. 사용자 계정 및 웹 상점에서 해시 된 암호를 사용 하 여 데이터베이스를 도용 하는 경우 다른 웹 사이트에서 사용 되는 암호를 사용할 수 있습니다.If they steal a database with user accounts and hashed password from a little web shop, they can use the passwords used on other web sites. 복잡 한 암호가 기억나지 않으므로 사용자는 항상 계정을 다시 사용 하는 경향이 있습니다.Users tend to reuse accounts all the time, because complex passwords are hard to remember. IT 부서의 경우 암호를 관리 하면 다시 설정 메커니즘을 제공 하 고, 암호를 자주 업데이트 해야 하며, 안전한 방식으로 저장 하는 것이 복잡 해질 수 있습니다.For an IT department, managing passwords also brings with it the complexity of having to offer reset mechanisms, requiring frequent updates to passwords, and storing them in a safe manner.

모든 단점에 대해, 단일 단계 인증은 자격 증명의 사용자 제어를 제공 합니다.For all of its disadvantages, single-factor authentication gives the user control of the credential. 인증서를 만들고 수정 하며 인증 프로세스에 대 한 키보드만 필요 합니다.They create it and modify it, and only a keyboard is needed for the authentication process. Multi-factor authentication의 단일 요소를 구분 하는 주요 측면입니다.This is the main aspect that distinguishes single-factor from multi-factor authentication.

2.1.1 웹 인증 브로커2.1.1 Web authentication broker

앞에서 설명한 것 처럼 IT 부서에서 암호 인증을 사용 하는 문제 중 하나는 사용자 이름/암호의 기본을 관리 하 고 메커니즘을 다시 설정 하는 등의 추가 오버 헤드입니다. 점차 널리 사용 되는 옵션은 인증을 위해 개방형 표준인 OAuth를 통해 인증을 제공 하는 타사 id 공급자를 사용 하는 것입니다.As previously discussed, one of the challenges with password authentication for an IT department is the added overhead of managing the base of usernames/passwords, reset mechanisms, etc. An increasingly popular option is to rely on third-party identity providers that offer authentication through OAuth, an open standard for authentication.

OAuth를 사용 하면 IT 부서에서 사용자 이름 및 암호를 사용 하 여 데이터베이스를 유지 관리 하 고, 암호 기능을 다시 설정 하는 것이 Facebook, Twitter, Microsoft 등의 타사 id 공급자로 효과적으로 "아웃소싱" 할 수 있습니다.Using OAuth, IT departments can effectively "outsource" the complexity of maintaining a database with usernames and passwords, reset password functionality, etc. to a third party identity provider like Facebook, Twitter or Microsoft.

사용자는 이러한 플랫폼에서 id를 완전히 제어할 수 있지만 사용자가 인증 된 후 인증 된 사용자에 게 권한을 부여 하는 데 사용할 수 있는 승인 된 후 앱에서 토큰을 요청할 수 있습니다.Users have complete control over their identity on these platforms, but apps can request a token from the provider, after the user is authenticated and with their consent, which can be used to authorize authenticated users.

Windows 10의 웹 인증 브로커는 응용 프로그램에서 OAuth 및 Openid connect와 같은 인증 및 권한 부여 프로토콜을 사용할 수 있는 Api 및 인프라 집합을 제공 합니다.The web authentication broker in Windows 10 provides a set of APIs and infrastructure for apps to use authentication and authorization protocols like OAuth and OpenID. 앱은 Webauthenticationbroker API를 통해 인증 작업을 시작할 수 있으며,이로 인해 webauthenticationbroker가 반환 됩니다.Apps can initiate authentication operations through the WebAuthenticationBroker API, resulting in the return of a WebAuthenticationResult. 통신 흐름의 개요는 다음 그림에 나와 있습니다.An overview of the communication flow is illustrated in the following figure.

wab 워크플로

앱은 브로커 역할을 하며 앱의 웹 보기 를 통해 id 공급자를 사용 하 여 인증을 시작 합니다.The app acts as the broker, initiating the authentication with the identity provider through a WebView in the app. Id 공급자는 사용자를 인증 한 경우 id 공급자 로부터 사용자에 대 한 정보를 요청 하는 데 사용할 수 있는 토큰을 앱에 반환 합니다.When the identity provider has authenticated the user, it returns a token to the app that can be used to request information about the user from the identity provider. 보안 조치로 id 공급자를 사용 하 여 인증 프로세스를 브로커 하려면 앱을 id 공급자에 등록 해야 합니다.As a security measure, the app must be registered with the identity provider before it can broker the authentication processes with the identity provider. 이 등록 단계는 공급자 마다 다릅니다.This registration steps differ for each provider.

Webauthenticationbroker API를 호출 하 여 공급자와 통신 하는 일반적인 워크플로는 다음과 같습니다.Here’s the general workflow for calling the WebAuthenticationBroker API to communicate with the provider.

  • Id 공급자에 게 보낼 요청 문자열을 생성 합니다.Construct the request strings to be sent to the identity provider. 문자열 수와 각 문자열의 정보는 각 웹 서비스에 대해 다르지만 일반적으로 URL을 포함 하는 두 개의 URI 문자열을 포함 합니다. 하나는 인증 요청을 보내는 것이 고, 하나는 권한 부여가 완료 된 후 사용자가 리디렉션되는 URL입니다.The number of strings, and the information in each string, is different for each web service but it usually includes two URI strings each containing a URL: one to which the authentication request is sent, and one to which the user is redirected after authorization is complete.
  • AuthenticateAsync를 호출 하 여 요청 문자열을 전달 하 고 id 공급자의 응답을 기다립니다.Call WebAuthenticationBroker.AuthenticateAsync, passing in the request strings, and wait for the response from the identity provider.
  • 응답이 수신 될 때 상태를 가져오려면 Webauthenticationresult. ResponseStatus 를 호출 합니다.Call WebAuthenticationResult.ResponseStatus to get the status when the response is received.
  • 통신이 성공적으로 완료 되 면 id 공급자가 반환 하는 응답 문자열을 처리 합니다.If the communication is successful, process the response string returned by the identity provider. 실패 한 경우 오류를 처리 합니다.If unsuccessful, process the error.

통신이 성공적으로 완료 되 면 id 공급자가 반환 하는 응답 문자열을 처리 합니다.If the communication is successful, process the response string returned by the identity provider. 실패 한 경우 오류를 처리 합니다.If unsuccessful, process the error.

이 프로세스에 대 한 샘플 c # 코드는 다음과 같습니다.Sample C# code that for this process is below. 자세한 내용 및 자세한 연습은 Webauthenticationbroker를 참조 하세요.For information and a detailed walkthrough, see WebAuthenticationBroker. 전체 코드 샘플을 보려면 GitHub의 Webauthenticationbroker 샘플을 확인 하세요.For a complete code sample, check out the WebAuthenticationBroker sample on GitHub.

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 multi-factor authentication2.2 Multi-factor authentication

Multi-factor authentication은 둘 이상의 인증 요소를 사용 합니다.Multi-factor authentication makes use of more than one authentication factor. 일반적으로 암호와 같은 "사용자가 알고 있는 것"은 휴대폰 또는 스마트 카드 일 수 있는 "보유 하 고 있는"와 결합 됩니다.Usually, "something you know," such as a password, is combined with "something you have," which can be a mobile phone or a smart card. 공격자가 사용자의 암호를 검색 하는 경우에도 장치 또는 카드 없이 계정에 액세스할 수 없습니다.Even if an attacker discovers the user’s password, the account is still inaccessible without the device or card. 장치 또는 카드만 손상 된 경우에는 암호 없이 공격자에 게 유용 하지 않습니다.And if only the device or card is compromised, it is not useful to the attacker without the password. 따라서 multi-factor authentication은 보다 안전 하지만 단일 단계 인증 보다 더 복잡 합니다.Multi-factor authentication is therefore more secure, but also more complex, than single-factor authentication.

Multi-factor authentication을 사용 하는 서비스는 사용자에 게 두 번째 자격 증명을 받는 방법에 대 한 선택 항목을 제공 하는 경우가 많습니다.Services that use multi-factor authentication will often give the user a choice in how they receive the second credential. 이러한 유형의 인증 예는 SMS를 사용 하 여 사용자의 휴대폰에 확인 코드를 전송 하는 일반적으로 사용 되는 프로세스입니다.An example of this type of authentication is a commonly used process where a verification code is sent to the user’s mobile phone using SMS.

  • 사용자가 id 공급자에 대 한 사용자 이름과 암호를 제공 합니다.The user provides their username and password to the identity provider.
  • Id 공급자는 사용자 이름 및 암호를 단일 단계 권한 부여에서 확인 한 후 시스템에 저장 된 사용자의 휴대폰 번호를 조회 합니다.The identity provider verifies the username and password as in single-factor authorization, and then looks up the user’s mobile phone number stored in the system.
  • 서버는 생성 된 확인 코드를 포함 하는 SMS 메시지를 사용자의 휴대폰으로 보냅니다.The server sends an SMS message containing a generated verification code to the user’s mobile phone.
  • 사용자가 id 공급자에 게 확인 코드를 제공 합니다. 사용자에 게 표시 되는 양식The user provides the verification code to the identity provider; through a form presented to the user.
  • Id 공급자는 두 자격 증명의 인증에 성공 했는지 여부를 나타내는 인증 상태를 반환 합니다.The identity provider returns an authentication status that indicates whether the authentication of both credentials were successful.
  • 성공 하면 데이터 교환이 시작 됩니다.If successful, data exchange begins. 그렇지 않으면 사용자를 다시 인증 해야 합니다.Otherwise, the user must be re-authenticated.

2 단계 인증

여기에서 볼 수 있듯이이 프로세스는 사용자가 만들거나 제공 하는 대신 두 번째 사용자 자격 증명이 사용자에 게 전송 된다는 점에서 단일 단계 인증과도 다릅니다.As you can see, this process also differs from single-factor authentication in that the second user credential is sent to the user instead of being created or provided by the user. 따라서 사용자는 필요한 자격 증명을 완벽 하 게 제어할 수 없습니다.The user is therefore not in complete control of the necessary credentials. 스마트 카드가 두 번째 자격 증명으로 사용 되는 경우에도 적용 됩니다. 조직에서 사용자에 게이를 만들고 제공 합니다.This also applies when a smart card is used as the second credential: the organization is in charge of creating and providing it to the user.

2.2.1 Azure Active Directory2.2.1 Azure Active Directory

Azure AD (Azure Active Directory)는 단일 단계 또는 multi-factor authentication에서 id 공급자로 사용할 수 있는 클라우드 기반 id 및 액세스 관리 서비스입니다.Azure Active Directory (Azure AD) is a cloud-based identity and access management service that can serve as the identity provider in single-factor or multi-factor authentication. 확인 코드를 사용 하거나 사용 하지 않고 Azure AD 인증을 사용할 수 있습니다.Azure AD authentication can be used with or without a verification code.

Azure AD는 단일 단계 인증을 구현할 수도 있지만 기업은 일반적으로 multi-factor authentication의 보안을 강화 해야 합니다.While Azure AD can also implement single-factor authentication, enterprises usually require the higher security of multi-factor authentication. Multi-factor authentication 구성에서 Azure AD 계정을 사용 하 여 인증 하는 사용자는 휴대폰 또는 Azure Authenticator 모바일 앱에 SMS 메시지로 전송 되는 확인 코드를 선택할 수 있습니다.In a multi-factor authentication configuration, a user authenticating with an Azure AD account has the option of having a verification code sent as an SMS message either to their mobile phone or the Azure Authenticator mobile app.

또한 Azure AD를 OAuth 공급자로 사용할 수 있으며, 표준 사용자에 게 다양 한 플랫폼에서 앱에 대 한 인증 및 권한 부여 메커니즘을 제공 합니다.Additionally, Azure AD can be used as an OAuth provider, providing the standard user with an authentication and authorization mechanism to apps across various platforms. 자세히 알아보려면 Azure의 Azure Active Directory 및 Multi-Factor Authentication를 참조 하세요.To learn more, see Azure Active Directory and Multi-Factor Authentication on Azure.

2.4 Windows Hello2.4 Windows Hello

Windows 10에서는 편리한 multi-factor authentication 메커니즘이 운영 체제에 기본 제공 됩니다.In Windows 10, a convenient multi-factor authentication mechanism is built into the operating system. Windows Hello는 Windows 10에 기본 제공 되는 새로운 생체 인식 로그인 시스템입니다.Windows Hello is the new biometric sign-in system built into Windows 10. Windows Hello는 운영 체제에 직접 빌드되기 때문에 사용자 장치의 잠금을 해제 하는 데 얼굴 또는 지문 id를 허용 합니다.Because it is built directly into the operating system, Windows Hello allows face or fingerprint identification to unlock users’ devices. Windows 보안 자격 증명 저장소는 장치에서 생체 인식 데이터를 보호 합니다.The Windows secure credential store protects biometric data on the device.

Windows Hello는 장치에서 개별 사용자를 인식할 수 있는 강력한 방법을 제공 하며,이를 통해 사용자와 요청 된 서비스 또는 데이터 항목 간의 경로에서 첫 번째 부분의 주소를 확인할 수 있습니다.Windows Hello provides a robust way for a device to recognize an individual user, which addresses the first part of the path between a user and a requested service or data item. 장치에서 사용자를 인식 한 후에도 요청 된 리소스에 대 한 액세스 권한을 부여할지 여부를 결정 하기 전에 사용자를 인증 해야 합니다.After the device has recognized the user, it still must authenticate the user before determining whether to grant access to a requested resource. Windows Hello는 Windows에 완전히 통합 되 고 재사용 가능한 암호를 특정 장치 및 생체 인식 제스처 나 PIN의 조합으로 대체 하는 강력한 2 단계 인증 (2FA)도 제공 합니다.Windows Hello also provides strong two-factor authentication (2FA) that is fully integrated into Windows and replaces reusable passwords with the combination of a specific device, and a biometric gesture or PIN. PIN은 Microsoft 계정 등록의 일부로 사용자가 지정 합니다.The PIN is specified by the user as part of their Microsoft account enrollment.

그러나 Windows Hello는 기존 2FA 시스템을 대체 하는 것은 아닙니다.Windows Hello isn’t just a replacement for traditional 2FA systems, though. 이는 개념적으로 스마트 카드와 유사 합니다. 인증은 문자열 비교 대신 암호화 기본 형식을 사용 하 여 수행 되 고 사용자의 키 자료는 변조 방지 하드웨어 내에서 안전 합니다.It’s conceptually similar to smart cards: authentication is performed by using cryptographic primitives instead of string comparisons, and the user’s key material is secure inside tamper-resistant hardware. Microsoft Hello에는 스마트 카드 배포에 필요한 추가 인프라 구성 요소가 필요 하지 않습니다.Microsoft Hello doesn't require the extra infrastructure components required for smart card deployment, either. 특히 인증서를 관리 하기 위해 PKI (공개 키 인프라)가 필요 하지 않습니다 (현재 없는 경우).In particular, you don’t need a Public Key Infrastructure (PKI) to manage certificates, if you don’t currently have one. Windows Hello는 스마트 카드의 주요 이점 (가상 스마트 카드에 대 한 배포 유연성 및 실제 스마트 카드에 대 한 강력한 보안)을 단점 없이 결합 합니다.Windows Hello combines the major advantages of smart cards—deployment flexibility for virtual smart cards and robust security for physical smart cards—without any of their drawbacks.

사용자가 인증 하려면 먼저 장치를 Windows Hello에 등록 해야 합니다.A device must be registered with Windows Hello before users can authenticate with it. Windows Hello는 한 당사자가 공개 키를 사용 하 여 다른 파티가 개인 키를 사용 하 여 암호를 해독할 수 있는 데이터를 암호화 하는 비대칭 (공개/개인 키) 암호화를 사용 합니다.Windows Hello uses asymmetric (public/private key) encryption in which one party uses a public key to encrypt the data that the other party can decrypt using a private key. Windows Hello의 경우 공개/개인 키 쌍 집합을 만들고 개인 키를 장치의 TPM (신뢰할 수 있는 플랫폼 모듈) 칩에 씁니다.In the case of Windows Hello, it creates a set of public/private key pairs and writes the private keys to the device’s Trusted Platform Module (TPM) chip. 장치를 등록 한 후 UWP 앱에서 시스템 Api를 호출 하 여 사용자의 공개 키를 검색할 수 있습니다 .이 키는 서버에서 사용자를 등록 하는 데 사용할 수 있습니다.After a device has been registered, UWP apps can call system APIs to retrieve the user’s public key, which can be used to register the user on the server.

앱의 등록 워크플로는 다음과 같습니다.The registration workflow of an app might look like the following:

windows hello 등록

수집 하는 등록 정보에는이 간단한 시나리오에서 수행 하는 것 보다 더 많은 식별 정보가 포함 될 수 있습니다.The registration information you collect may include a lot more identifying information than it does in this simple scenario. 예를 들어 앱이 은행에 대해 하나의 보안 서비스에 액세스 하는 경우 등록 프로세스의 일부로 id 및 기타 사물 증명을 요청 해야 합니다.For example, if your app accesses a secured service such as one for banking, you’d need to request proof of identity and other things as part of the sign-up process. 모든 조건이 충족 되 면이 사용자의 공개 키는 백 엔드에 저장 되 고 다음에 사용자가 서비스를 사용할 때의 유효성을 검사 하는 데 사용 됩니다.Once all the conditions are met, the public key of this user will be stored in the back-end and used to validate the next time the user uses the service.

Windows Hello에 대 한 자세한 내용은 windows hello 가이드windows hello 개발자 가이드를 참조 하세요.For more information on Windows Hello, see the Windows Hello guide and the Windows Hello developer guide.

3 데이터 비행 보안 방법3 Data-in-flight security methods

데이터 비행 보안 방법은 네트워크에 연결 된 장치 간에 전송 되는 데이터에 적용 됩니다.Data-in-flight security methods apply to data in transit between devices connected to a network. 데이터는 개인 회사 인트라넷의 보안 수준이 높은 환경에서 시스템이 나 웹의 비보안 환경에서 클라이언트와 웹 서비스 간에 전송 될 수 있습니다.The data may be transferred between systems on the high-security environment of a private corporate intranet, or between a client and web service in the non-secure environment of the web. Windows 10 앱은 네트워킹 Api를 통해 SSL과 같은 표준을 지원 하 고, 개발자가 앱에 적절 한 수준의 보안을 보장할 수 있는 Azure API Management와 같은 기술을 사용 하 여 작업 합니다.Windows 10 apps support standards such as SSL through their networking APIs, and work with technologies such as Azure API Management with which developers can ensure the appropriate level of security for their apps.

3.1 원격 시스템 인증3.1 Remote system authentication

원격 컴퓨터 시스템과의 통신이 발생하게 되는 두 가지 일반적인 시나리오가 있습니다.There are two general scenarios where communication occurs with a remote computer system.

  • 로컬 서버는 직접 연결을 통해 사용자를 인증 합니다.A local server authenticates a user over a direct connection. 예를 들어 서버와 클라이언트가 회사 인트라넷에 있는 경우입니다.For example, when the server and the client are on a corporate intranet.
  • 웹 서비스는 인터넷을 통해와 통신 합니다.A web service is communicated with over the Internet.

웹 서비스 통신에 대 한 보안 요구 사항은 데이터는 더 이상 보안 네트워크의 일부일 뿐 아니라 악의적인 공격자가 데이터를 가로챌 가능성이 높기 때문에 직접 연결 시나리오 보다 더 높습니다.Security requirements for web service communication are higher than those in direct connection scenarios, as data is no longer only a part of a secure network and the likelihood of malicious attackers looking to intercept data is also higher. 다양 한 유형의 장치가 서비스에 액세스 하기 때문에 WCF와는 달리 RESTful 서비스로 빌드됩니다. 예를 들어 서비스에 대 한 인증 및 권한 부여를 통해 새로운 과제가 도입 됩니다.Because various types of devices will access the service, they will likely be built as RESTful services, as opposed to WCF, for instance, which means authentication and authorization to the service also introduces new challenges. 보안 원격 시스템 통신을 위한 두 가지 요구 사항에 대해 설명 합니다.We’ll discuss two requirements for secure remote system communication.

첫 번째 요구 사항은 메시지 기밀성이 있습니다. 즉, 클라이언트와 웹 서비스 간에 전달 되는 정보 (예: 사용자의 id 및 기타 개인 정보)는 전송 중에 제 3 자가 읽을 수 없어야 합니다.The first requirement is message confidentiality: The information passed between the client and the web services (for example, the identity of the user and other personal information) must not be readable by third parties while in transit. 이 작업은 일반적으로 메시지가 전송되는 연결을 암호화하고 메시지 자체를 암호화하여 수행됩니다.This is usually accomplished by encrypting the connection over which messages are sent and by encrypting the message itself. 개인/공개 키 암호화에서는 공개 키를 누구나 사용할 수 있으며 특정 수신자에 게 보낼 메시지를 암호화 하는 데 사용 됩니다.In private/public key encryption, the public key is available to anyone, and is used to encrypt messages to be sent to a specific receiver. 개인 키는 수신자만 보유 하 고 메시지의 암호를 해독 하는 데 사용 됩니다.The private key is only held by the receiver and is used to decrypt the message.

두 번째 요구 사항은 메시지 무결성입니다. 클라이언트와 웹 서비스는 수신 하는 메시지가 상대방에 게 전송 하려는 메시지 인지, 전송 중에 변경 되지 않았는지를 확인할 수 있어야 합니다.The second requirement is message integrity: The client and the web service must be able to verify that the messages they receive are the ones intended to be sent by the other party, and that the message has not been altered in transit. 이는 디지털 서명을 사용 하 여 메시지를 서명 하 고 인증서 인증을 사용 하 여 수행 됩니다.This is accomplished by signing messages with digital signatures and using certificate authentication.

3.2 SSL 연결3.2 SSL connections

클라이언트에 대 한 보안 연결을 설정 하 고 유지 관리 하기 위해 웹 서비스는 HTTPS (보안 하이퍼텍스트 전송 프로토콜)에서 지원 되는 SSL(Secure Sockets Layer) (SSL)를 사용할 수 있습니다.To establish and maintain secure connections to clients, web services can use Secure Sockets Layer (SSL), which is supported by the Secure Hypertext Transfer Protocol (HTTPS). SSL은 서버 인증서 뿐만 아니라 공개 키 암호화를 지원 하 여 메시지 기밀성과 무결성을 제공 합니다.SSL provides message confidentiality and integrity by supporting public key encryption as well as server certificates. SSL은 TLS (전송 계층 보안)로 대체 되지만 TLS는 일반적으로 SSL (보통 수준의) 이라고 합니다.SSL is superseded by Transport Layer Security (TLS), but TLS is often casually referred to as SSL.

클라이언트에서 서버에 있는 리소스에 대 한 액세스를 요청 하면 SSL은 서버와의 협상 프로세스를 시작 합니다.When a client requests access to a resource on a server, SSL starts a negotiation process with the server. 이를 SSL 핸드셰이크 라고 합니다.This is called an SSL handshake. 암호화 수준, 공개 및 개인 암호화 키 집합, 클라이언트 및 서버 인증서의 id 정보는 SSL 연결 기간 동안 모든 통신의 기반으로 합의 됩니다.An encryption level, a set of public and private encryption keys, and the identity information in the client and server certificates are agreed upon as the basis of all communication for the duration of the SSL connection. 서버에서 지금 클라이언트를 인증 해야 할 수도 있습니다.The server may also require the client to be authenticated at this time. 연결이 설정 되 면 연결이 닫힐 때까지 모든 메시지가 협상 된 공개 키로 암호화 됩니다.Once the connection is established, all messages are encrypted with the negotiated public key until the connection closes.

3.2.1 SSL 고정3.2.1 SSL pinning

SSL은 암호화 및 인증서를 사용 하 여 메시지 기밀성을 제공할 수 있지만 클라이언트가 통신 하는 서버가 올바른 서버 인지 확인 하는 것은 아무 작업도 수행 하지 않습니다.While SSL can provide message confidentiality using encryption and certificates, it does nothing to verify that the server with which the client is communicating is the correct one. 서버 동작은 권한이 없는 타사에 의해 모방 될 수 있으며, 클라이언트에서 전송 하는 중요 한 데이터를 가로챌 수 있습니다.The server’s behavior can be mimicked by an unauthorized third-party, intercepting the sensitive data that the client transmits. 이를 방지 하기 위해 SSL 고정 이라는 기술은 서버의 인증서가 클라이언트에서 예상 하 고 신뢰 하는 인증서 인지 확인 하는 데 사용 됩니다.To prevent this, a technique called SSL pinning is used to verify that the certificate on the server is the certificate that the client expects and trusts.

앱에서 SSL 고정을 구현 하는 몇 가지 다른 방법이 있습니다. 각 방법에는 고유한 장단점이 있습니다.There are a few different ways to implement SSL pinning in apps, each with their own pros and cons. 가장 쉬운 방법은 응용 프로그램의 패키지 매니페스트에 있는 인증서 선언을 통하는 것입니다.The easiest approach is via the Certificates declaration in the app’s package manifest. 이 선언을 사용 하면 앱 패키지에서 디지털 인증서를 설치 하 고 해당 인증서에 독점적인 신뢰를 지정할 수 있습니다.This declaration enables the app package to install digital certificates and specify exclusive trust in them. 그러면 인증서 체인에 해당 인증서가 있는 앱과 서버 간에만 SSL 연결이 허용 됩니다.This results in SSL connections being allowed only between the app and servers that have the corresponding certificates in their certificate chain. 또한이 메커니즘을 사용 하면 신뢰할 수 있는 공용 인증 기관에서 타사 종속성이 필요 하지 않으므로 자체 서명 된 인증서를 안전 하 게 사용할 수 있습니다.This mechanism also enables the secure use of self-signed certificates, as no third party dependency is needed on trusted public certification authorities.

ssl 매니페스트

유효성 검사 논리를 보다 효과적으로 제어 하기 위해 Api를 사용 하 여 HTTPS 요청에 대 한 응답으로 서버에서 반환 된 인증서의 유효성을 검사할 수 있습니다.For more control over the validation logic, APIs are available to validate the certificate(s) returned by the server in response to an HTTPS request. 이 메서드는 요청을 보내고 응답을 검사 해야 하므로 실제로 요청에서 중요 한 정보를 보내기 전에이를 유효성 검사로 추가 해야 합니다.Note that this method requires sending a request and inspecting the response, so be sure to add this as a validation before actually sending sensitive information in a request.

다음 c # 코드는이 SSL 고정 메서드를 보여 줍니다.The following C# code illustrates this method of SSL pinning. Validatesslroot 메서드는 httpclient 클래스를 사용 하 여 HTTP 요청을 실행 합니다.The ValidateSSLRoot method uses the HttpClient class to execute an HTTP request. 클라이언트에서 응답을 보낸 후에는 RequestMessage ServerIntermediateCertificates 컬렉션을 사용 하 여 서버에서 반환 된 인증서를 검사 합니다.After the client sends the response, it uses the RequestMessage.TransportInformation.ServerIntermediateCertificates collection to inspect the certificates returned by the server. 클라이언트는 포함 된 지문을 사용 하 여 전체 인증서 체인의 유효성을 검사할 수 있습니다.The client can then validate the entire certificate chain with the thumbprints it has included. 이 방법에서는 서버 인증서가 만료 되 고 갱신 될 때 앱에서 인증서 지문을 업데이트 해야 합니다.This method does require the certificate thumbprints to be updated in the app when the server certificate expires and is renewed.

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에 대 한 액세스 게시 및 보안3.3 Publishing and securing access to REST APIs

웹 서비스에 대 한 인증 된 액세스를 보장 하려면 API 호출을 수행할 때마다 인증을 요구 해야 합니다.To ensure authorized access to web services, they must require authentication every time an API call is made. 성능 및 확장을 제어 하는 것은 웹 서비스가 웹에서 노출 될 때 고려해 야 할 사항입니다.Being able to control performance and scale is also something to consider when web services are exposed across the web. Azure API Management는 웹을 통해 Api를 노출 하는 데 사용할 수 있는 서비스 이며 세 가지 수준에 기능을 제공 합니다.Azure API Management is a service that can help expose APIs across the web, while providing features on three levels.

API의 게시자 /관리자 는 Azure API Management의 게시자 포털을 통해 쉽게 api를 구성할 수 있습니다.Publishers/Administrators of the API can easily configure the API through the Publisher Portal of Azure API Management. 여기에서 API 집합을 만들 수 있으며 해당 집합에 대 한 액세스를 관리 하 여 Api에 액세스할 수 있는 사용자를 제어할 수 있습니다.Here, API sets can be created and access to them can be managed to control who has access to which APIs.

이러한 Api에 대 한 액세스를 요청 하는 개발자 는 개발자 포털을 통해 요청을 수행할 수 있습니다 .이 포털은 즉시 액세스를 제공 하거나 게시자/관리자가 승인을 요구할 수 있습니다.Developers wanting access to these APIs can make requests through the Developer Portal, which can either immediately provide access or require approval by the publisher/administrator. 개발자는 또한 개발자 포털에서 API 설명서 및 샘플 코드를 보고 웹 서비스에서 제공 하는 Api를 신속 하 게 채택할 수 있습니다.Developers can also view the API documentation and sample code in the Developer Portal, to rapidly adopt the APIs offered by the web service.

이러한 개발자가 만드는 은 Azure API Management에서 제공 하는 프록시를 통해 API에 액세스 합니다.The apps that these developers create then access the API through the proxy offered by Azure API Management. 프록시는 모두 은둔 계층을 제공 하 고, 게시자/관리자 서버에서 API의 실제 끝점을 숨기고, api 변환과 같은 추가 논리를 포함 하 여 한 API에 대 한 호출이 다른 API에 리디렉션되는 경우 노출 되는 API가 일관 되 게 유지 되도록 할 수도 있습니다.The proxy both provides a layer of obscurity, hiding the actual end-point of the API on the publisher/administrator’s server and can also include additional logic like API translation to ensure the exposed API is kept consistent when a call to one API is redirected to another. 또한 IP 필터링을 사용 하 여 특정 IP 도메인 또는 도메인 집합에서 시작 되는 API 호출을 차단할 수 있습니다.It can also use IP filtering to block API calls originating from a specific IP domain or set of domains. 또한 Azure API Management는 API 키 라는 공개 키 집합을 사용 하 여 각 API 호출을 인증 하 고 권한을 부여 하 여 웹 서비스를 안전 하 게 유지 합니다.Azure API Management also keeps its web services secure by using a set of public keys, called API keys, to authenticate and authorize each API call. 권한 부여가 실패 하면 API에 대 한 액세스 및 지원 되는 기능이 차단 됩니다.When authorization fails, access to the API and the functionality it supports is blocked.

Azure API Management는 웹 서비스의 성능을 최적화 하기 위해 서비스 (제한 이라는 프로시저)에 대 한 API 호출 수를 줄일 수도 있습니다.Azure API Management can also reduce the number of API calls to a service (a procedure called throttling) to optimizes the performance of the web service. 자세히 알아보려면 AzureCon 2015에서 azure API Managementazure API Management를 검토 하세요.To learn more, review Azure API Management and Azure API Management at AzureCon 2015.

4 개의 미사용 데이터 보안 방법4 Data-at-rest security methods

데이터가 장치에 도착 하면이를 "미사용 데이터"로 지칭 합니다.When data arrives on a device, we refer to it as "data-at-rest." 이 데이터는 권한이 없는 사용자 또는 앱에서 액세스할 수 없도록 장치에 안전 하 게 저장 해야 합니다.This data needs to be stored on the device in a secure manner, so that it cannot be accessed by unauthorized users or apps. Windows 10의 앱 모델은 응용 프로그램에 의해 저장 된 데이터에만 액세스할 수 있도록 하는 동시에 필요한 경우 데이터를 공유 하는 Api를 제공 합니다.The app model in Windows 10 does a lot to ensure that the data stored by any app is only accessible to that app, while providing APIs to share the data when necessary. 추가 Api를 사용 하 여 데이터를 암호화 하 고 자격 증명을 안전 하 게 저장할 수 있는지도 확인할 수 있습니다.Additional APIs are also available to ensure that data can be encrypted and credentials can be stored safely.

4.1 Windows 앱 모델4.1 Windows app model

일반적으로 Windows에는 앱의 정의가 없습니다.Traditionally, Windows has never had a definition of an app. 가장 일반적으로 실행 파일 (.exe) 이라고 하며,이는 설치, 상태 저장, 실행 길이, 버전 관리, OS 통합 또는 앱 간 통신을 포함 하지 않습니다.It was most commonly referred to as an executable (.exe), and this never included installation, storage of state, execution length, versioning, OS integration, or app-to-app communication. 유니버설 Windows 플랫폼 모델은 설치, 런타임 환경, 리소스 관리, 업데이트, 데이터 모델 및 제거를 포함 하는 앱 모델을 정의 합니다.The Universal Windows Platform model defines an app model that covers installation, runtime environment, resource management, updates, data model, and uninstallation.

Windows 10 앱은 컨테이너에서 실행 됩니다. 즉, 기본적으로 권한이 제한 되어 있습니다 (사용자가 추가 권한을 요청 하 고 부여할 수 있음).Windows 10 apps run in a container, which means that they have limited privileges by default (additional privileges can be requested and granted by the user). 예를 들어 응용 프로그램이 시스템의 파일에 액세스 하려는 경우에는 파일에 대 한 직접 액세스를 사용 하도록 설정 하지 않고, 사용자가 파일을 선택 하는 데 사용 해야 하는 경우에는 Windows. . i m l 네임 스페이스의 파일 선택기를 사용 해야 합니다.For example, if an app wants to access files on the system, a file picker from the Windows.Storage.Pickers namespace has to be used to let the user pick a file (no direct access to files is enabled). 또 다른 예는 응용 프로그램이 사용자의 위치 데이터에 액세스 하려는 경우 위치 장치 기능을 선언 해야 하는 위치를 사용 하도록 설정 해야 하며, 사용자에 게이 앱에서 사용자의 위치에 대 한 액세스를 요청 하는 메시지가 표시 되는 경우입니다.Another example is if an app wants to access the user’s location data, it needs to enable the location device capability needs to be declared, prompting the user at download time that this app will request access to the user’s location. 처음에는 앱에서 사용자의 위치에 처음 액세스 하려고 할 때 사용자에 게 데이터 액세스 권한을 요청 하는 추가 동의 프롬프트가 표시 됩니다.On top of that, the first time the app wants to access the user’s location, an additional consent prompt is shown to the user, requesting permission to access the data.

이 앱 모델은 응용 프로그램에 대 한 "감옥"으로 작동 합니다. 즉,이 모델은 외부에서 연결할 수 없는 "성"은 아닙니다 (관리자 권한이 있는 응용 프로그램은 여전히에 도달할 수 있음).Note that this app model acts as a "jail" for apps, meaning that they can’t reach out, but it is not a “castle” that cannot be reached from the outside (applications with administrator privileges can of course still reach in). 조직/IT에서 실행할 수 있는 (Win32) 앱을 지정할 수 있도록 하는 Windows 10의 Device Guard는이 액세스를 제한 하는 데 도움이 될 수 있습니다.Device Guard in Windows 10, which enables organizations/IT to specify which (Win32) apps are allowed to execute, can further help limit this access.

앱 모델은 또한 앱 수명 주기를 관리 합니다.The app model also manages the app lifecycle. 기본적으로 앱의 백그라운드 실행을 제한 합니다. 예를 들어 앱이 백그라운드에 들어가면 프로세스가 일시 중단 되 고, 코드에서 앱 일시 중단을 해결 하는 짧은 기간을 앱에 제공 하 고 해당 메모리가 고정 됩니다.It limits the background execution of apps by default, for example; as soon as an app goes into the background, the process is suspended – after giving the app a brief period to address app suspension in code – and its memory is frozen. 운영 체제는 앱에서 특정 백그라운드 작업 실행을 요청 하는 메커니즘 (예: 인터넷/Bluetooth 연결, 전원 변경 등의 다양 한 이벤트에 의해 트리거되는 일정에 따라, 음악 재생 또는 GPS 추적 등의 특정 시나리오)을 제공 합니다.The operating system does provide mechanisms for apps to ask for specific background task execution (on a schedule, triggered by various events such as Internet/Bluetooth connectivity, power changes, etc., and in specific scenarios such as music playing or GPS tracking).

장치의 메모리 리소스가 부족 하 게 되 면 Windows는 앱을 종료 하 여 메모리 공간을 확보 합니다.When memory resources on the device are running low, Windows frees memory space by terminating apps. 이 수명 주기 모델은 일시 중단 및 종료 사이에 사용할 수 있는 추가 시간이 없기 때문에 앱이 일시 중단 될 때마다 데이터를 유지 하도록 합니다.This lifecycle model forces apps to persist data whenever they’re suspended, because there is no additional time available between suspension and termination.

자세한 내용은 범용: Windows 10 응용 프로그램의 수명 주기 이해를 참조 하세요.For more information, see It's Universal: Understanding the Lifecycle of a Windows 10 Application.

4.2 저장 된 자격 증명 보호4.2 Stored credential protection

인증 된 서비스에 액세스 하는 Windows 앱은 종종 사용자에 게 로컬 장치에 자격 증명을 저장 하는 옵션을 제공 합니다.Windows apps that access authenticated services often provide the users the option of storing their credentials on the local device. 사용자가 편리 하 게 사용할 수 있습니다. 사용자의 사용자 이름과 암호를 제공 하면 앱은 다음에 앱을 시작할 때 자동으로 사용 합니다.This is a convenience for the users; when they provide their username and password, the app automatically uses them in subsequent launches of the app. 공격자가이 저장 된 데이터에 액세스할 수 있는 경우 보안 문제가 될 수 있으므로 windows 10은 Windows 앱이 보안 자격 증명 보관에 사용자 자격 증명을 저장 하는 기능을 제공 합니다.Because this can be a security issue if an attacker gains access to this stored data, Windows 10 provides the ability for Windows apps to store user credentials in a secure credential locker. 앱은 자격 증명 보관 API를 호출 하 여 앱의 저장소 컨테이너에 자격 증명을 저장 하는 대신 보관 하 고 자격 증명을 검색 합니다.The app calls the Credential Locker API to store and retrieve the credentials from the locker instead of storing them in the app’s storage container. 자격 증명 보관은 운영 체제에서 관리 되지만 액세스는 자격 증명 저장소에 안전 하 게 관리 되는 솔루션을 제공 하 여 저장 하는 앱 으로만 제한 됩니다.The credential locker is managed by the operating system, but access is limited to the app that stores them, providing a securely managed solution for credential storage.

사용자가 저장할 자격 증명을 제공 하면 앱은 PasswordVault 네임 스페이스의 PasswordVault 개체를 사용 하 여 자격 증명 보관에 대 한 참조를 가져옵니다.When a user supplies the credentials to be stored, the app gets a reference to the credential locker using the PasswordVault object in the Windows.Security.Credentials namespace. 그런 다음 Windows 앱에 대 한 식별자와 사용자 이름 및 암호를 포함 하는 Passwordcredential 개체를 만듭니다.It then creates a PasswordCredential object containing an identifier for the Windows app and the username and password. 이는 자격 증명을 보관에 저장 하기 위해 PasswordVault 메서드로 전달 됩니다.This is passed to the PasswordVault.Add method to store the credentials in the locker. 다음 c # 코드 예제에서는이 작업을 수행 하는 방법을 보여 줍니다.The following C# code example shows how this is done.

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

다음 c # 코드 예제에서 앱은 PasswordVault 개체의 FindAllByResource 메서드를 호출 하 여 앱에 해당 하는 모든 자격 증명을 요청 합니다.In the following C# code example, the app requests all of the credentials corresponding to the app by calling the FindAllByResource method of the PasswordVault object. 둘 이상의가 반환 되 면 사용자에 게 사용자 이름을 입력 하 라는 메시지가 표시 됩니다.If more than one is returned, it prompts the user to enter their username. 자격 증명이 보관에 없으면 앱에서 사용자에 게 해당 자격 증명을 묻는 메시지를 표시 합니다.If the credentials are not in the locker, the app prompts the user for them. 그런 다음 사용자는 자격 증명을 사용 하 여 서버에 로그인 합니다.The user is then logged into the server using the credentials.

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();
    var credentialList = vault.FindAllByResource(resourceName);

    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;
}

자세한 내용은 자격 증명보관을 참조 하세요.For more information, see Credential locker.

4.3 저장 된 데이터 보호4.3 Stored data protection

일반적으로 미사용 데이터 라고 하는 저장 된 데이터를 처리 하는 경우 암호화를 사용 하면 권한이 없는 사용자가 저장 된 데이터에 액세스 하지 못할 수 있습니다.When you are dealing with stored data, commonly referred to as data-at-rest, encrypting it can prevent unauthorized users from accessing the stored data. 데이터를 암호화 하는 두 가지 일반적인 메커니즘은 대칭 키를 사용 하거나 비대칭 키를 사용 하는 것입니다.The two common mechanisms to encrypt data are using either symmetric keys or using asymmetric keys. 그러나 데이터 암호화는 데이터가 전송 된 시간과 저장 된 시간 사이에 변경 되지 않도록 보장할 수 없습니다.However, data encryption can’t ensure that the data is unaltered between the time it was sent and the time it was stored. 즉, 데이터 무결성을 보장할 수 없습니다.In other words, the data integrity cannot be ensured. 메시지 인증 코드, 해시 및 디지털 서명을 사용 하는 것은이 문제를 해결 하는 일반적인 기술입니다.Using message authentication codes, hashes, and digital signing are common techniques to solve this problem.

4.3.1 데이터 암호화4.3.1 Data encryption

대칭 암호화를 사용 하 여 보낸 사람과 받는 사람이 모두 동일한 키를 사용 하 여 데이터를 암호화 하 고 암호 해독 하는 데 사용 합니다.With symmetric encryption, both the sender and recipient have the same key and use it to both encrypt and decrypt the data. 이 방법의 과제는 키를 안전 하 게 공유 하 여 두 당사자가 모두 인식 한다는 것입니다.The challenge with this approach is securely sharing the key so both parties are aware of it.

이에 대 한 한 가지 대답은 공개/개인 키 쌍이 사용 되는 비대칭 암호화입니다.One answer to this is asymmetric encryption, in which a public/private key pair is used. 공개 키는 메시지를 암호화 하려는 사용자와 자유롭게 공유 됩니다.The public key is shared freely with anyone who wants to encrypt a message. 개인 키는 데이터를 암호 해독 하는 데만 사용할 수 있도록 항상 암호를 유지 합니다.The private key is always kept secret so that only you can use it to decrypt the data. 공개 키의 검색을 허용 하는 일반적인 방법은 디지털 인증서를 사용 하는 것입니다 (인증서 라고도 함).A common technique to allow for discovery of the public key is by using digital certificates, also simply referred to as certificates. 인증서는 사용자 또는 서버에 대 한 정보 (예: 이름, 발급자, 전자 메일 주소 및 국가) 뿐만 아니라 공개 키에 대 한 정보를 저장 합니다.The certificate holds information about the public key, in addition to information about the user or server such as the name, issuer, email address and country.

Windows 앱 개발자는 SymmetricKeyAlgorithmProviderAsymmetricKeyAlgorithmProvider 클래스를 사용 하 여 UWP 앱에서 대칭 및 비대칭 암호화를 구현할 수 있습니다.Windows app developers can use the SymmetricKeyAlgorithmProvider and AsymmetricKeyAlgorithmProvider classes to implement symmetric and asymmetric encryption in their UWP apps. 또한 CryptographicEngine 클래스를 사용 하 여 데이터를 암호화 및 암호 해독 하 고, 콘텐츠에 서명 하 고, 디지털 서명을 확인할 수 있습니다.Additionally, the CryptographicEngine class can be used to encrypt and decrypt data, sign content and verify digital signatures. 앱은 DataProtectionProvider 네임 스페이스DataProtectionProvider 클래스를 사용 하 여 저장 된 로컬 데이터를 암호화 하 고 해독할 수도 있습니다.Apps can also use the DataProtectionProvider class in the Windows.Security.Cryptography.DataProtection namespace to encrypt and decrypt stored local data.

메시지 변조를 검색 하는 4.3.2 (Mac, 해시 및 서명)4.3.2 Detecting message tampering (MACs, hashes, and signatures)

MAC은 대칭 키 (비밀 키) 또는 메시지를 MAC 암호화 알고리즘에 대 한 입력으로 사용 하 여 생성 되는 코드 또는 태그입니다.A MAC is a code (or tag) that results from using a symmetric key (called the secret key) or a message as input to a MAC encryption algorithm. 비밀 키와 알고리즘은 메시지를 전송 하기 전에 발신자와 수신자에 의해 합의 됩니다.The secret key and the algorithm are agreed upon by the sender and receiver before the message transfer.

Mac은 다음과 같은 메시지를 확인 합니다.MACs verify messages like this.

  • 발신자는 비밀 키를 MAC 알고리즘에 대 한 입력으로 사용 하 여 MAC 태그를 파생 합니다.The sender derives the MAC tag by using the secret key as input to the MAC algorithm.
  • 보낸 사람이 MAC 태그와 메시지를 받는 사람에 게 보냅니다.The sender sends the MAC tag and the message to the receiver.
  • 수신기는 비밀 키와 메시지를 MAC 알고리즘에 대 한 입력으로 사용 하 여 MAC 태그를 파생 합니다.The receiver derives the MAC tag by using the secret key and the message as inputs to the MAC algorithm.
  • 수신자는 해당 MAC 태그를 발신자의 MAC 태그와 비교 합니다.The receiver compares their MAC tag with the sender's MAC tag. 동일한 경우에는 메시지가 변조 되지 않았음을 알 수 있습니다.If they are the same then we know that the message has not been tampered with.

mac 확인

Windows 앱은 MacAlgorithmProvider 클래스를 호출 하 여 mac 암호화 알고리즘을 수행 하는 Key 및 CryptographicEngine 클래스를 생성 하 여 mac 메시지 확인을 구현할 수 있습니다.Windows apps can implement MAC message verification by calling the MacAlgorithmProvider class to generate the key and CryptographicEngine class to perform the MAC encryption algorithm.

해시를 사용 하 여 4.3.34.3.3 Using hashes

해시 함수는 임의의 long 데이터 블록을 사용 하 고 해시 값 이라는 고정 크기 비트 문자열을 반환 하는 암호화 알고리즘입니다.A hash function is a cryptographic algorithm that takes an arbitrarily long block of data and returns a fixed-size bit string called a hash value. 이 작업을 수행할 수 있는 전체 해시 함수 패밀리가 있습니다.There is an entire family of hash functions that can do this.

위의 메시지 전송 시나리오에서 MAC 대신 해시 값을 사용할 수 있습니다.A hash value can be used in place of a MAC in the message-transfer scenario above. 발신자는 해시 값과 메시지를 보내고 수신자는 보낸 사람의 해시 값과 메시지에서 고유한 해시 값을 파생 시키고 두 해시 값을 비교 합니다.The sender sends a hash value and a message, and the receiver derives their own hash value from the sender's hash value and message and compares the two hash values. Windows 10에서 실행 되는 앱은 HashAlgorithmProvider 클래스를 호출 하 여 사용할 수 있는 해시 알고리즘을 열거 하 고 그 중 하나를 실행할 수 있습니다.Apps running on Windows 10 can call the HashAlgorithmProvider class to enumerate the hash algorithms that are available and run one of them. CryptographicHash 클래스는 해시 값을 나타냅니다.The CryptographicHash class represents the hash value. CryptographicHash 메서드를 사용 하 여 각 사용에 대 한 개체를 다시 만들지 않고도 다른 데이터를 반복적으로 해시 하는 데 사용할 수 있습니다.The CryptographicHash.GetValueAndReset method can be used to repeatedly hash different data without having to re-create the object for each use. CryptographicHash 클래스의 Append 메서드는 해시 될 버퍼에 새 데이터를 추가 합니다.The Append method of the CryptographicHash class adds new data to a buffer to be hashed. 이 전체 프로세스는 다음 c # 코드 예제에 나와 있습니다.This entire process is shown in the following C# code example.

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 디지털 서명4.3.4 Digital signatures

디지털 서명 된 저장 메시지의 데이터 무결성은 MAC 인증과 비슷한 방식으로 확인 됩니다.The data integrity of a digitally signed stored message is verified in a similar way to MAC authentication. 디지털 서명 워크플로의 작동 방식은 다음과 같습니다.Here is the way the digital signature workflow operates.

  • 보낸 사람은 해시 알고리즘에 대 한 입력으로 메시지를 사용 하 여 해시 값 (다이제스트 라고도 함)을 파생 합니다.The sender derives a hash value (also known as a digest) by using the message as the input to a hash algorithm.
  • 발신자는 개인 키를 사용 하 여 다이제스트를 암호화 합니다.The sender encrypts the digest using their private key.
  • 보낸 사람은 메시지, 암호화 된 다이제스트 및 사용 된 해시 알고리즘의 이름을 보냅니다.The sender sends the message, the encrypted digest, and the name of the hash algorithm that was used.
  • 수신자는 공개 키를 사용 하 여 받은 암호화 된 다이제스트의 암호를 해독 합니다.The receiver uses the public key to decrypt the encrypted digest it received. 그런 다음 해시 알고리즘을 사용 하 여 메시지를 해시 하 여 자체의 다이제스트를 만듭니다.It then uses the hash algorithm to hash the message to create a digest of its own. 마지막으로 수신기는 두 다이제스트 (수신 하 고 해독 한 다이제스트와 자신이 만든 다이제스트)를 비교 합니다.And finally the receiver compares the two digests (the one it received and decrypted, and the one it made). 두 개의 일치 항목이 수신자가 메시지를 개인 키의 소유자나에서 보냈는지 확인할 수 있는 경우에만이 메시지는 개인 키의 메시지에 의해 전송 되 고 메시지가 전송 중에 변경 되지 않았음을 확인할 수 있습니다.Only if the two match can the receiver be sure that the message was sent by the possessor of the private key, and therefore they are who they say they are, and that the message was not altered in transit.

디지털 서명

해시 알고리즘은 매우 빠르기 때문에 큰 메시지에서 해시 값을 신속 하 게 파생 시킬 수 있습니다.Hashing algorithms are very fast, so hash values can be derived quickly from even large messages. 결과 해시 값은 임의 길이 이며 전체 메시지 보다 짧을 수 있으므로 공개 키와 개인 키를 사용 하 여 전체 메시지가 아니라 다이제스트만 암호화 하 고 해독 하면 됩니다.The resulting hash value is an arbitrary length and can be shorter than the full message, so using public and private keys to encrypt and decrypt only the digest rather than the full message is an optimization.

자세한 내용은 디지털 서명, mac, 해시, 서명및 암호화에 대 한 문서를 참조 하세요.For more information, take a look articles on Digital signatures, MACs, hashes, and signatures, and Cryptography.

5 요약5 Summary

Windows 10의 유니버설 Windows 플랫폼는 운영 체제 기능을 활용 하 여 더 안전한 앱을 만드는 여러 가지 방법을 제공 합니다.The Universal Windows Platform in Windows 10 offers a number of ways to leverage operating system capabilities to create more secure apps. OAuth id 공급자를 사용 하 여 단일 요소, multi-factor 또는 조정 된 인증과 같은 다양 한 인증 시나리오에서 Api는 인증을 사용 하 여 가장 일반적인 문제를 완화 하기 위해 존재 합니다.In different authentication scenarios, such as single-factor, multi-factor, or brokered authentication with an OAuth identity provider, APIs exist to mitigate the most common challenges with authentication. Windows Hello는 사용자를 인식 하 고 적절 한 식별을 회피 하기 위해 적극적으로 노력 하는 새로운 생체 인식 로그인 시스템을 제공 합니다.Windows Hello provides a new biometric sign-in system that recognizes the user and actively defeats efforts to circumvent proper identification. 또한 신뢰할 수 있는 플랫폼 모듈 외부에서 표시 하거나 사용할 수 없는 여러 계층의 키 및 인증서를 제공 합니다.It also delivers multiple layers of keys and certificates that can never be revealed or used outside the trusted platform module. 또한 증명 id 키 및 인증서를 선택적으로 사용 하 여 추가 보안 계층을 사용할 수 있습니다.Plus, a further layer of security is available through the optional use of attestation identity keys and certificates.

비행 중인 데이터를 보호 하기 위해 Api는 ssl을 통해 안전 하 게 원격 시스템과 통신 하는 데 사용 되 고, SSL 고정으로 서버 인증의 유효성을 검사할 수 있는 가능성을 제공 합니다.To secure data in flight, APIs exist to communicate with remote systems securely over SSL, while providing the possibility to validate the server’s authenticity with SSL pinning. Api를 안전 하 고 제어 된 방식으로 게시 하면 API 끝점의 난독 처리를 추가로 제공 하는 프록시를 사용 하 여 웹에서 Api를 노출 하기 위한 강력한 구성 옵션을 제공 하 여 Azure API Management 지 원하는 것입니다.Publishing APIs securely and in a controlled manner is something in which Azure API Management aids by providing powerful configuration options for exposing APIs across the web using a proxy that provides additional obfuscation of the API endpoint. Api 키를 사용 하 여 이러한 Api에 대 한 액세스를 보호 하 고, API 호출을 제한 하 여 성능을 제어할 수 있습니다.Access to these APIs is secured by using API keys and API calls can be throttled to control performance.

데이터가 장치에 도착할 때 Windows 앱 모델은 앱을 설치 하 고, 업데이트 하 고, 액세스 하는 방법을 제어 하는 동시에 권한 없는 방식으로 다른 앱의 데이터에 액세스할 수 있도록 합니다.When the data arrives on the device, the Windows app model provides more control over how the app is installed, updated and accesses it data, while keeping it from accessing data of other apps in an unauthorized manner. 자격 증명 보관은 운영 체제에서 관리 하는 사용자 자격 증명의 보안 저장소를 제공할 수 있으며, 유니버설 Windows 플랫폼에서 제공 하는 암호화 및 해시 Api를 사용 하 여 장치에서 기타 데이터를 보호할 수 있습니다.Credential locker can provide secure storage of user credentials that is managed by the operating system and other data can be protected on the device by using the encryption and hashing APIs offered by the Universal Windows Platform.

6 리소스6 Resources

6.1 방법 문서6.1 How-to articles

6.2 코드 샘플6.2 Code samples

6.3 API 참조6.3 API reference