Preventing Insecure Network Connections - 네트워크 보안

앱 내에서 안전한 네트워크 링크를 강화하기 위해 App Transport Security에 의존하세요.

 

Overview

Apple 플랫폼에서는 App Transport Security (ATS)라는 네트워킹 보안 기능이 모든 앱 및 앱 확장에 대한 개인 정보 보호와 데이터 무결성을 향상시킵니다. App Transport Security(ATS)는 앱에서 생성하는 네트워크 연결이 신뢰할 수 있는 인증서 및 암호를 사용하여 Transport Layer Security (TLS) 프로토콜에 의해 보호되도록 하는 것으로 이루어집니다. ATS는 최소 보안 요구 사항을 충족하지 않는 연결을 차단합니다.

간단하게 네트워킹을 해주는 URLSession이라는 박스 안에 ATS라는 네트워킹 보안 기능이 있어 앱이 안전한 통신을 유지하도록 해주며 TLS는 ATS로 보안적으로 안전한 URLSession 박스를 어떻게 상대방한테 전달할지 결정하는 방법(프로토콜)입니다.

 

ATS는 기본적으로 iOS 9.0 이상 또는 macOS 10.11 SDK 이상에 링크된 앱에서 작동합니다. 완전히 안전하지 않은 서버에 연결해야 하고 더 안전하게 구성할 수 없는 경우, ATS 요구 사항을 완화하기 위해 예외를 추가할 수 있습니다.

iOS 9.0 또는 macOS 10.11보다 오래된 SDK에 앱을 연결하면, 앱이 실행되는 운영 체제 버전에 관계없이 ATS가 비활성화됩니다.

 

앱에서 High-Level 프레임워크 선호

시스템은 표준 URL Loading System을 사용할 때 ATS를 강제로 적용합니다. URLSession의 인스턴스는 자동으로 서버에서 제공하는 가장 안전한 연결을 협상합니다. 앱이 취해야 하는 유일한 조치는 https로 시작하는 안전한 URL을 사용하는 것입니다. 그렇지 않으면 ATS가 연결을 거부하고 다음과 같은 콘솔 메시지를 출력합니다

App Transport Security has blocked a cleartext HTTP (http://) resource load since it is insecure. Temporary exceptions can be configured via your app's Info.plist file.

 

ATS는 앱이 Network framework 또는 CFNetwork와 같은 낮은 수준의 네트워킹 인터페이스에 대한 호출에는 적용되지 않습니다. 이러한 경우에서는 개발자가 연결의 보안을 보장하기 위한 책임을 져야합니다. 이 방법으로 안전한 연결을 생성할 수 있지만, 실수가 발생하기 쉽고 비용이 많이 듭니다. 일반적으로는 URL Loading System에 의존하는 것이 가장 안전합니다.

URL Loading System 이란?

URL Loading System은 https와 같은 표준 프로토콜 또는 사용자가 생성하는 사용자 정의 프로토콜을 사용하여 URL에 식별된 리소스에 액세스하는 기능을 제공합니다. Loading은 비동기적으로 수행되므로 앱은 응답을 할 수 있도록 유지되고 데이터나 오류가 도착하는 대로 처리할 수 있습니다.

 

URLSession 인스턴스으로 하나 또는 그 이상의 데이터 및 파일들을 get 하거나 데이터를 post할 수 있는 URLSessionTask 인스턴스를 만들 수 있습니다. URLSession을 구성하려면 URLSessionConfiguration 객체를 사용합니다. 이 객체는 캐시 및 쿠키 사용 방법, 또는 셀룰러 네트워크에서의 연결 허용 여부와 같은 동작을 제어합니다.

 

하나의 URLSession을 사용하여 반복적인 작업을 만들 수 있습니다. 예를 들어 웹 프라우저가 다른 일반 세션과 데이터를 저장하지 않는 개인정보 보호 세션으로 나누는 경우 다음 그림처럼 2개의 세션이 여러개의 작업을 수행할 수 있습니다.

 

각 세션은 주기적인 업데이트(또는 오류)를 받기 위한 delegate와 연관되어 있습니다. 기본 delegate는 제공한 완료 핸들러 블록을 호출하며, 사용자 정의 delegate를 제공하기로 선택하면 이 블록이 호출되지 않습니다.
세션을 백그라운드에서 실행하도록 구성할 수 있으므로 앱이 일시 중단된 동안 시스템이 데이터를 다운로드하고 결과를 전달하기 위해 앱을 깨울 수 있습니다.

 

최소 요구 사항을 충족하는 네트워크 서버 보장

안전한 서버는 X.509 디지털 인증서를 사용하여 그 신원을 확립합니다. 연결하는 클라이언트는 이 인증서를 검사하여 기본 서버 신뢰 평가를 수행합니다. 이 평가에는 다음과 같은 인증서가 포함되어 있는지 확인하는 사항이 포함됩니다:

• 디지털 서명이 있는지 확인하여 인증서가 변경되지 않았음을 나타냅니다.
• 만료되지 않았는지 확인합니다.
• 서버의 DNS 이름과 일치하는 이름을 가지고 있는지 확인합니다.
• 다른 유효한 인증서에 의해 서명되었으며, 이 인증서는 다시 다른 인증서에 의해 서명되어 등등 신뢰할 수 있는 앵커 인증서까지 거슬러 올라갑니다. 이 앵커 인증서는 Certificate Authority (CA)에 의해 발급되어야 합니다. 앵커 인증서는 iOS의 사용 가능한 신뢰할 수 있는 루트 인증서 목록이나 사용자 또는 시스템 관리자에 의해 클라이언트에 설치되어야 합니다.

ATS는 이러한 사항을 모두 요구하고 확장된 보안 확인을 제공합니다:

• 서버 인증서는 적어도 2048비트의 Rivest-Shamir-Adleman (RSA) 키 또는 적어도 256비트의 타원 곡선 암호화 (ECC) 키로 서명되어야 합니다.
• 인증서는 적어도 256비트 (즉, SHA-256 이상)의 Secure Hash Algorithm 2 (SHA-2)를 사용해야 합니다.
• 연결은 Transport Layer Security (TLS) 프로토콜 버전 1.2 이상을 사용해야 합니다.
• 데이터는 AES-128 또는 AES-256 대칭 암호를 사용하여 교환되어야 합니다.
• 링크는 타원 곡선 디피-헬만 에페멀 (ECDHE) 키 교환을 통해 완벽한 전송 보안 (PFS)을 지원해야 합니다.

필요할 때만 예외 구성; 서버 수정 우선

ATS는 서버가 바로 위에서 논의한 보안 검사 중 하나를 통과하지 못하면 연결을 허용하지 않습니다. 가장 좋은 대응은 서버를 업데이트하는 것입니다. 어떤 이유로 인해 그렇게 할 수 없는 경우 앱에서 ATS의 하나 이상의 측면을 비활성화하는 예외를 지정할 수 있습니다.

중요
ATS 실패에 직면했을 때 항상 서버를 수정하는 것이 더 나은 방법입니다. 예외는 앱의 보안을 감소시킵니다. 일부 예외는 앱을 앱 스토어에 제출할 때 설명된 것처럼 정당화가 필요할 수 있습니다.

 

ATS 예외를 구성하려면 앱의 Information Property List 파일에서 선택적인 NSAppTransportSecurity 키의 값으로 사전을 제공합니다. 이 사전은 다음과 같은 구조를 가지며 모든 키는 선택적입니다:

NSAppTransportSecurity : Dictionary {
    NSAllowsArbitraryLoads : Boolean
    NSAllowsArbitraryLoadsForMedia : Boolean
    NSAllowsArbitraryLoadsInWebContent : Boolean
    NSAllowsLocalNetworking : Boolean
    NSExceptionDomains : Dictionary {
        <domain-name-string> : Dictionary {
            NSIncludesSubdomains : Boolean
            NSExceptionAllowsInsecureHTTPLoads : Boolean
            NSExceptionMinimumTLSVersion : String
            NSExceptionRequiresForwardSecrecy : Boolean
            NSRequiresCertificateTransparency : Boolean
        }
    }
}

 

NSAppTransportSecurity 사전의 첫 번째 수준의 키는 NSExceptionDomains 하위 사전에서 명시적으로 지정되지 않은 모든 도메인에 대한 연결에 적용됩니다. 예를 들어 NSAllowsArbitraryLoads를 YES로 설정하면 모든 네트워크 연결에 대해 ATS를 완전히 비활성화합니다.

 

사용 사례에 따라 더 좁은 예외를 제공할 수 있습니다. 예를 들어 NSAllowsArbitraryLoadsInWebContent를 YES로 설정하면 WKWebView와 같은 웹 뷰 내에서 수행된 호출에 대한 ATS 제약을 비활성화할 수 있습니다.

 

만약 특정 도메인에 대해서만 ATS 제약을 비활성화 시키고 싶을 경우 예를 들어 안전이 확보되지 않은 http://example.com 이라는 서버 도메인에 접속해야할 때 NSExceptionAllowsInsecureHTTPLoads를 YES로 하여 다른 도메인들은 ATS를 유지하며 해당 도메인만 제약을 비활성화 시킬 수 있습니다.

참고
전역 예외는 NSExceptionDomains 사전에 추가하는 도메인에는 적용되지 않습니다. 따라서 이전 예제를 반전시켜서 example.com을 제외한 모든 도메인에서 불안전한 트래픽을 허용하려면 NSAllowsArbitraryLoads를 제일 위에 배치하고 NSExceptionDomains에 빈 example.com 사전을 예외 도메인으로 포함하면 됩니다.

 

ATS 실패의 원인을 빠르게 찾고 필요한 예외를 결정하는 데 도움이 되도록 nscurl 명령 줄 도구를 사용하여 다양한 ATS 예외 조합으로 서버에 연결할 수 있습니다. 자세한 내용은 여기 참조하십시오.

 

정당한 예외 사유

앱의 Information Property List 파일에 특정 ATS 예외를 추가하려면 정당한 이유를 제공해야 하며, 이로 인해 앱에 대한 추가적인 App Store 검토가 발생할 수 있습니다. 정당화가 필요한 예외는 다음과 같습니다:
- 임의의 연결 예외 (NSAllowsArbitraryLoads)
- 미디어 스트리밍 예외 (NSAllowsArbitraryLoadsForMedia)
- 웹 콘텐츠 로드 (NSAllowsArbitraryLoadsInWebContent)
- 도메인별 비보안 연결 (NSExceptionAllowsInsecureHTTPLoads)
- 도메인별 최소 TLS 버전 (NSExceptionMinimumTLSVersion)

고려 대상이 되는 정당화의 몇 가지 예시는 다음과 같습니다:
- 앱은 안전한 연결을 지원하지 않는 다른 엔터티가 관리하는 서버에 연결해야 합니다.
- 앱은 안전한 연결을 사용하도록 업그레이드할 수 없는 기기에 연결해야 하며, 공개 호스트 이름을 사용하여 액세스해야 합니다.
- 앱은 다양한 소스에서 임베디드 웹 콘텐츠를 표시해야 하지만 웹 콘텐츠 예외에서 지원하는 클래스를 사용할 수 없습니다.
- 앱은 암호화된 미디어 콘텐츠를 로드하며 개인 정보가 포함되지 않습니다.

앱을 App Store에 제출할 때, 기본적으로 보안 연결을 생성할 수 없는 이유를 App Store가 결정할 수 있도록 충분한 정보를 제공해야 합니다.

 

 

 

 

더 나아가 App Transport Security가 네트워크 연결을 거부할 경우 이유를 알고싶으면 여기를 참고하세요