login register Sysop! about ME  
qrcode
    최초 작성일 :    2017년 05월 10일
  최종 수정일 :    2017년 05월 10일
  작성자 :    soggun
  편집자 :    soggun (송원석)
  읽음수 :    3,147

강좌 목록으로 돌아가기

필자의 잡담~

이번 컬럼은 ASP.NET Core 데이터 보안 강좌 중에서 데이터 보호에 대한 개요를 다루는 글입니다.

모든 컬럼은 http://docs.asp.net의 내용을 참고하여 번역한 것입니다. Windows 뿐만 아니라 Linxu, OS X에서도 동작하는 완전한 크로스 플랫폼 서버기술인 ASP.NET Core! 기대해 주세요.

본 번역문서는 개인적인 취지로 번역되어 제공되는 문서로, 원문을 비롯한 모든 저작권은 마이크로소프트사에 있습니다. 마이크로소프트사의 요청이 있을 경우, 언제라도 게시가 중단될 수 있습니다. 본 번역문서에는 오역이 포함되어 있을 수 있으며 주석도 번역자 개인의 견해일뿐입니다. 마이크로소프트사는 본 문서의 번역된 내용에 대해 일체의 보장을 하지 않습니다. 번역이 완료된 뒤에도 제품이 업그레이드 되거나 기능이 변경됨에 따라 원문도 변경되거나 보완되었을 수 있으므로 참고하시기 바랍니다.

원문: https://docs.microsoft.com/ko-kr/aspnet/core/security/data-protection/using-data-protection

데이터 보호 개요

웹 응용 프로그램에서 보안에 민감한 데이터를 저장해야 할 경우가 종종 있습니다. Windows는 비슷한 경우에 데스크탑 응용 프로그램에서 사용할 수 있는 DPAPI를 제공해주지만, 이 API는 웹 응용 프로그램에는 적합하지 않습니다. ASP.NET Core 데이터 보호(ASP.NET Core Data Protection) 스택은 개발자가 키 관리 및 순환 같은 데이터 보호 작업에 사용할 수 있는, 간단하고 사용이 용이한 암호화 API를 제공합니다.

ASP.NET Core 데이터 보호 스택은 장기적으로 ASP.NET 1.x - 4.x의 <machinekey> 요소를 대체하기 위한 목적으로 설계되었습니다. 기존 암호화 스택의 많은 단점들을 해결하는 한편, 현대적인 응용 프로그램에서 접하기 마련인 대다수의 사용 사례에 즉각적으로 대응할 수 있는 솔루션을 제공하도록 설계되었습니다.

문제 설명

전체적인 문제를 한 문장으로 간단 명료하게 정리할 수 있습니다: "나중에 조회하기 위한 신뢰할 수 있는 정보를 유지하고자 하지만, 지속성 메커니즘을 신뢰하지는 않는다"는 것입니다. 즉, 웹의 관점에서 다시 말하자면 "신뢰할 수 있는 상태를 신뢰할 수 없는 클라이언트를 이용해서 왕복(Round-Trip)해야 한다"고 할 수 있습니다.

대표적인 사례로 인증 쿠키나 전달자 토큰(Bearer Token)을 들 수 있습니다. 가령 서버가 "나는 Groot고 xyz 권한을 갖고 있다"라는 토큰을 생성한 다음, 이를 클라이언트로 전달합니다. 이후 특정 시점에 클라이언트가 다시 서버로 토큰을 제출하지만, 서버로서는 클라이언트가 해당 토큰을 변조하지 않았다는 어떤 보장이 필요합니다. 따라서 필요한 첫 번째 요건은 신뢰성(Authenticity)입니다 (무결성(Integrity) 또는 변조 방지(Tamper-Proofing)하고도 합니다).

그리고 저장된 상태(정보)를 신뢰하는 주체는 서버이므로, 우리는 이 상태에 운영 환경 고유의 정보가 포함되어 있을 수도 있음을 예상할 수 있습니다. 아마도 이 정보는 파일 경로, 권한, 핸들 혹은 그 밖의 간접 참조, 또는 서버 고유의 데이터 중 일부 같은 형태를 띄고 있을 것입니다. 일반적으로 이런 정보들은 신뢰할 수 없는 클라이언트에게 공개되지 않습니다. 따라서 필요한 두 번째 요건은 기밀성(Confidentiality)입니다.

마지막으로 현대적인 응용 프로그램은 구성 요소를 기반으로 구축되므로, 각 개별 구성 요소는 시스템의 다른 구성 요소들과 관계 없이 데이터 보호 스택을 활용할 수 있어야 합니다. 예를 들어서, 전달자 토큰 구성 요소가 데이터 보호 스택을 사용한다면, 역시 같은 스택을 사용하는 CSRF 방지 메커니즘에 간섭 받지 않고 동작할 수 있어야 합니다. 따라서 필요한 마지막 요건은 격리(Isolation)입니다.

더 많은 제약 조건을 규정해서 필요 요건의 범위를 좁힐 수 있습니다. 암호화 시스템 내에서 동작하는 모든 서비스를 동등하게 신뢰할 수 있으며, 직접 제어하는 서비스 외부에서 데이터가 생성되거나 소비될 필요가 없다고 가정합니다. 또한, 웹 서비스에 대한 각 요청들이 암호화 시스템을 여러 번 거칠 수도 있기 때문에 최대한 빠르게 작업을 처리해야 합니다. 결론적으로 이런 시나리오에는 대칭 암호화가 적절하며, 필요해질 때까지 비대칭 암호화에 대해서는 무시할 수 있습니다.

설계 철학

먼저 우리는 기존 스택과 관련된 문제점을 확인하는 작업에 착수했습니다. 이 작업을 마치고 기존 솔루션들의 현황을 조사해본 결과, 기존 솔루션에는 원하는 기능들이 전혀 존재하지 않는다는 결론을 내렸습니다. 이후, 다음과 같은 몇 가지 기본 원칙에 따라 솔루션을 설계했습니다.

  • 시스템 구성 방식이 간단해야 합니다. 이상적으로는 특별히 시스템을 구성하지 않고도(Zero-Configuration) 개발자들이 작업하는데 전혀 지장이 없어야 합니다. 개발자가 (키 리파지터리 같은) 특정 측면을 구성해야 할 경우, 해당 특정 구성을 간단히 처리할 수 있는 방법이 제공되어야 합니다.

  • 간단한 소비자 지향적인 API를 제공해야 합니다. 이 API는 올바르게 사용하기는 쉽고 잘못 사용하기는 어려워야 합니다.

  • 개발자가 주요 관리 원칙을 배울 필요가 없어야 합니다. 시스템이 개발자 대신 알고리즘을 선택하고 키의 수명을 처리해야 합니다. 이상적으로는 개발자가 가공되지 않은 키 자료에 접근조차 할 필요가 없어야 합니다.

  • 가능하다면 저장된 비활성 키를 보호해야 합니다. 또한, 시스템이 적절한 기본 보호 메커니즘을 찾아서 이를 자동으로 적용해야 합니다.

이런 원칙들을 기반으로 간단하고 사용하기 쉬운 데이터 보호 스택을 개발했습니다.

ASP.NET Core 데이터 보호 API는 기밀 페이로드를 무기한 저장하기 위한 의도로 설계되지 않았습니다. 무기한 저장 시나리오에는 Windows CNG DPAPIAzure 권한 관리(Azure Rights Management) 같은 다른 기술들이 더 적합하며, 그에 상응하는 강력한 키 관리 기능을 갖추고 있습니다. 그렇지만 개발자가 ASP.NET Core 데이터 보호 API를 사용해서 기밀 데이터를 장기간 보호하는 것을 강력하게 금지하지는 않습니다.

대상 그룹

데이터 보호 시스템은 다섯 가지 주요 패키지로 구분됩니다. 이런 API들의 다양한 측면들은 세 가지 주요 대상 그룹을 목표로 삼고 있습니다:

  1. 소비자 API(Consumer APIs)는 응용 프로그램 및 프레임워크 개발자를 대상으로 합니다.

    "나는 스택의 동작 방식이나 구성 방법을 배우고 싶지는 않습니다. 단지 APIs를 성공적으로 사용할 개연성이 높은 가장 간단한 방법으로 특정 작업을 수행하기만 하면 됩니다."

  2. 구성 API(Configuration APIs)는 응용 프로그램 개발자 및 시스템 관리자를 대상으로 합니다.

    "내가 작업 중인 환경이 기본 경로가 아니거나 별도의 설정을 필요로 한다는 점을 데이터 보호 시스템에게 알릴 필요가 있습니다."

  3. 확장성 API는 사용자 지정 정책 구현을 담당하는 개발자를 대상으로 합니다. 이런 API들을 사용해야 되는 경우는 드물며, 경험이 풍부한 보안 인식이 높은 개발자들만을 대상으로 국한됩니다.

    "나는 매우 독특한 동작 요건 때문에 시스템 내의 전체 구성 요소를 교체해야 합니다. 요건을 만족하는 플러그인을 구축하기 위해서 일반적으로는 잘 사용되지 않는 API 표면을 배우려고 합니다."

패키지 레이아웃

데이터 보호 스택은 다섯 개의 패키지로 구성됩니다.

  • Microsoft.AspNetCore.DataProtection.Abstractions 패키지에는 가장 기본이 되는 IDataProtectionProvider 인터페이스와 IDataProtector 인터페이스가 포함되어 있습니다. 그리고 추가적으로 이 형식들을 이용한 작업을 보조해주는 유용한 확장 메서드들이 함께 포함되어 있습니다 (예, IDataProtector.Protect의 오버로드). 보다 자세한 정보는 소비자 API(Consumer APIs) 문서를 참고하시기 바랍니다. 다른 누군가가 데이터 보호 시스템의 인스턴스를 생성하는 역할을 수행하고, 여러분은 단지 API를 사용하기만 한다면 Microsoft.AspNetCore.DataProtection.Abstractions 패키지를 참조하면 됩니다.

  • Microsoft.AspNetCore.DataProtection 패키지에는 핵심 암호화 작업, 키 관리, 구성, 그리고 확장성 같은 데이터 보호 시스템의 중추를 구성하는 구현들이 포함되어 있습니다. 데이터 보호 시스템의 인스턴스를 생성해야 한다거나 (예, IServiceCollection에 추가하는 등), 그 동작을 변경 또는 확장해야 한다면 Microsoft.AspNetCore.DataProtection 패키지를 참조해야 합니다.

  • Microsoft.AspNetCore.DataProtection.Extensions 패키지에는 개발자가 유용하게 사용할 수 있는, 핵심 패키지에는 속하지 않는 추가적인 API들이 포함되어 있습니다. 예를 들어서, 이 패키지에는 "의존성 주입 설정 없이 특정 키 저장소 디렉터리를 가리키는 시스템의 인스턴스를 생성하는" 간단한 API가 포함되어 있습니다. 또한, 보호되는 페이로드의 수명을 제한하는 확장 메서드도 여기에 포함되어 있습니다.

  • Microsoft.AspNetCore.DataProtection.SystemWeb 패키지를 기존의 ASP.NET 4.x 응용 프로그램에 설치하면 그 내부의 <machinekey> 처리 대신 새로운 데이터 보호 스택을 사용하도록 재지정할 수 있습니다. 보다 자세한 정보는 호환성 관련 문서를 참고하시기 바랍니다.

  • Microsoft.AspNetCore.Cryptography.KeyDerivation 패키지는 PBKDF2 비밀번호 해싱 루틴 구현을 제공하며 사용자의 비밀번호를 안전하게 처리해야 하는 시스템에서 사용할 수 있습니다. 보다 자세한 정보는 Password Hashing 문서를 참고하시기 바랍니다.


authored by


 
 
.NET과 Java 동영상 기반의 교육사이트

로딩 중입니다...

서버 프레임워크 지원 : NeoDEEX
based on ASP.NET 3.5
Creative Commons License
{5}
{2} 읽음   :{3} ({4})