블로그

모든 것이 안전한 시대의 규모

로리 맥비티 썸네일
로리 맥비티
2016년 7월 7일 게시

모바일 분야의 거물은 지난 6월 Apple의 WWDC(World Wide Developer Conference)에서 2017년 1월 1일부터 앱 스토어의 모든 앱이 앱 전송 보안(ATS)을 반드시 사용해야 한다고 발표했습니다 (네트워크 전문가를 위해 RFC 스타일로 설명드리자면).

기본적으로 앱이 HTTP 대신 HTTPS를 사용하도록 강제합니다.

이제 이것이 사람들에게 의미하는 바는 그들이 할 수 있는 일이 불과 몇 달뿐이라는 것입니다.

  1. 모바일 앱 업데이트
    이건 당연한 것 같네요. 결국, iOS 모바일 앱은 HTTPS를 사용해야 합니다. 그렇죠, 그게 있죠.
  2. 백엔드에서 HTTPS 지원
    이는 그리 명확하지 않을 수 있지만 HTTPS의 주요 목적은 최소한 두 당사자가 참여하는 통신을 보호하는 것입니다. 모바일 앱의 경우 온프레미스 또는 클라우드에 있는 일종의 엔드포인트(앱, 서비스, API 게이트웨이)입니다. 이 역시 HTTPS를 지원해야 합니다.

첫 번째 요구 사항보다 두 번째 요구 사항이 기술적으로나 운영적으로 더 복잡합니다. 단순히 스위치를 켜는 것만으로는 안 되기 때문입니다. HTTPS를 지원하지 않던 웹 서버와 API 게이트웨이에 대한 인증서 및 키 관리, 배포, 업그레이드, 구성 변경이 있습니다. 지원하기 위해 인프라(및 아키텍처)에 광범위한 변경이 필요할 수 있습니다. 그리고 인증서 만료일을 감시하고 이를 교체하는 것을 포함하여 해야 할 운영상의 변경 사항이 있습니다.

모든 것이 안전한 시대에 확장하는 것은 단순히 용량의 문제가 아니라 운영 역량의 문제입니다. 안전한 앱 인프라를 지원하는 데 있어 운영에 미치는 영향은 사소하지 않습니다. 그것은 단순한 체크박스나 새로운 설정 파일이 아닙니다.

1. 프로세스 변경

"DevOps를 수행 중"(또는 수행하지 않는 경우)인 경우 배포 파이프라인 프로세스를 검토하고 HTTPS를 지원하는 데 필요한 구성 요소가 포함되어 있는지 확인해야 합니다. 즉, 키, 인증서 및 구성이 프로세스에 포함되어야 합니다.

2. 경영진 변경

인증서는 만료됩니다. 그리고 그들이 그렇게 할 때 그것은 나쁜 일입니다™. 운영 부서는 인증서가 만료되는 시기를 알아야 하며 해당 인증서를 갱신하고 배포하는 프로세스가 있는지 확인해야 합니다(기본적으로 GOTO #1 - 프로세스 변경).

3. 용량 변경

암호화와 복호화는 컴퓨팅 측면에서 비용이 저렴하지 않습니다. 예전만큼 탐욕스럽지 않더라도 안전한 연결은 여전히 안전하지 않은 연결보다 더 많은 리소스를 소모합니다. 사용자가 매우 적은 앱의 경우 눈에 띄는 차이가 없을 수도 있습니다. 하지만 동시에 많이 사용되는 경우 확장에 사용할 수 있는 용량을 조사해야 합니다. 서버(가상 또는 물리적)뿐만 아니라 인프라도 중요합니다. 여기에는 API 게이트웨이(또는 API 게이트웨이처럼 작동하는 장치/시스템)와 잠재적으로 서비스 레지스트리(이미 컨테이너와 마이크로서비스를 사용 중인 경우)가 포함됩니다.

4. 건축적 변화

종단 간 보안 연결은 사용자와 앱 간의 모든 보안 서비스를 마비시켜, 민감한 데이터에 액세스할 수 있는 앱이나 서비스에 맬웨어나 악성 코드가 도달하는 것을 막는 데 사실상 무용지물이 됩니다. 보안 연결을 가로채고 검사할 수 있는 기능(요청 시와 응답 시 모두)은 성공적인 보안 전략의 중요한 구성 요소입니다. 중요한 보안 인프라가 침해와 감염을 예방하는 역할을 수행하는 데 필요한 가시성을 계속 확보하려면 구조적 변경이 필요할 수 있습니다.

핵심 네트워크에서 보안 연결을 관리하는 2계층 아키텍처는 앱 인프라 전반에 인증서와 키가 퍼져 있음으로 인해 발생하는 운영상의 어려움을 크게 완화할 수 있습니다. 보안 연결은 보안 프록시를 통해 코어 네트워크에서 종료될 수 있기 때문입니다. 원하는 경우 백엔드 앱과의 통신은 일반 텍스트로 계속 유지할 수 있으며, 종단 간 보안 통신을 유지하기 위해 다시 암호화할 수도 있습니다. 암호화되지 않은 데이터는 추가 검사를 위해 보안 솔루션(IDS/IPS 등)에 미러링할 수 있으며, 기존 인프라에 대한 투자를 그대로 유지할 수 있습니다. 즉, 인증서와 키를 배포, 관리, 모니터링하는 중앙 위치가 하나 필요하다는 의미입니다. 또한 모바일 <—> 앱 통신을 방해하지 않고 가로채기와 검사가 발생할 수 있는 NS 데이터 경로의 전략적 지점을 제공합니다.

2단

그럼에도 불구하고 앱(모바일 및 기타)에 대한 모든 것을 보호하는 접근 방식이 규모에 미치는 영향은 컴퓨팅 리소스 문제일 뿐만 아니라 운영상의 문제이기도 합니다. 애플이 이러한 변화를 주도하고 있는 것은 분명하지만, 애플만이 변화를 주도하는 것은 아닙니다. 공식 표준에서 HTTP/2에 대한 SSL/TLS 요구 사항이 제거되었음에도 불구하고 웹 브라우저 커뮤니티는 SSL/TLS를 통해서만 HTTP/2를 지원할 것입니다. 즉, 웹의 많은 부분이 HTTP/1x에서 HTTP/2로 전환됨에 따라 Secure Everything의 범위는 계속 확장될 것입니다.

앱과 사용자 간의 암호화되지 않은 모든 종류의 통신을 없애려는 이러한 지속적인 노력(명령 또는 기능)은 일부 조직의 경우 프로세스와 제품에서도 상당한 변경을 요구할 것입니다.