계획 4단계: 애플리케이션 보안 계획

아티클
07/19/2023

웹 사이트 작성 과정의 이 단계에서는 ASP.NET 응용 프로그램의 보안 요구 사항을 고려합니다. 다음 섹션에서는 IIS 8에서 사용할 수 있는 애플리케이션 보안 설정에 대해 설명합니다.

4.1. 웹 애플리케이션 격리

웹 애플리케이션의 보안을 향상시키는 가장 효율적인 방법 중 하나는 웹 서버의 다른 애플리케이션으로부터 웹 애플리케이션을 격리하는 것입니다. 애플리케이션 풀에는 요청을 처리하고 애플리케이션 코드를 실행하는 고유한 작업자 프로세스가 있습니다. 작업자 프로세스에는 SID(보안 식별자)가 있습니다. 그리고 각 애플리케이션 풀에는 고유한 애플리케이션 풀 ID가 있습니다. 기본적으로 웹 애플리케이션을 만들면 애플리케이션과 같은 이름의 새 애플리케이션 풀도 생성됩니다. 웹 애플리케이션을 별도의 애플리케이션 풀에 유지하는 경우 서로 격리할 수 있습니다.

웹 애플리케이션 격리 시 다음 작업이 수행됩니다.

사이트 격리: 각 애플리케이션을 서로 다른 애플리케이션 풀의 개별 사이트로 분리합니다.
최소 권한: 사이트별로 고유한 낮은 권한의 ID(가상 애플리케이션 풀 ID)로 작업자 프로세스를 실행합니다.
임시 격리: 사이트당 별도의 ASP.NET 임시 폴더를 설정하고 적절한 프로세스 ID에 대한 액세스 권한만 부여합니다.
콘텐츠 격리: 해당하는 프로세스 ID에만 액세스를 허용하도록 각 사이트 루트의 ACL(액세스 제어 목록)을 설정합니다.

팁

웹 사이트 및 웹 애플리케이션 콘텐츠는 시스템 드라이브(C:)가 아닌 드라이브에서 호스트하는 것이 좋습니다.

4.2. .NET 신뢰 수준

응용 프로그램 신뢰 수준은 ASP.NET CAS(코드 액세스 보안) 정책이 부여하는 권한을 결정합니다. CAS는 완전 신뢰와 부분 신뢰의 두 가지 신뢰 범주를 정의합니다. 완전 신뢰의 권한이 있는 응용 프로그램은 서버의 모든 리소스 종류에 액세스할 수 있으며 권한 작업을 수행할 수 있습니다. 완전 신뢰 응용 프로그램에는 운영 체제의 보안 설정만이 적용됩니다.

부분 신뢰 웹 응용 프로그램은 완전히 신뢰되지 않으며 제한적인 코드 액세스 권한 집합을 포함하는 응용 프로그램입니다. 따라서 부분 신뢰 응용 프로그램에서는 보안된 리소스 액세스 및 기타 권한 작업 수행 기능이 제한됩니다. 부분 신뢰 응용 프로그램의 경우 특정 권한이 거부되므로 해당 권한이 있어야 하는 리소스에 직접 액세스할 수 없습니다. 그 외의 권한은 제한된 방식으로 부여되기 때문에 해당 권한이 있어야 하는 리소스에도 제한된 방식으로만 액세스할 수 있습니다. 예를 들어 제한된 파일 I/O 권한이 있는 응용 프로그램은 응용 프로그램의 가상 디렉터리 루트 아래에 있는 디렉터리에 한해 파일 시스템에 액세스할 수 있습니다.

웹 응용 프로그램 또는 웹 서비스에 대해 부분 신뢰를 구성하면 중요 시스템 리소스 또는 다른 웹 응용 프로그램에 속하는 리소스에 대한 응용 프로그램의 액세스 기능을 제한할 수 있습니다. 응용 프로그램에 필요한 권한만 부여하고 더 이상의 권한은 부여하지 않으면 최소 권한 웹 응용 프로그램을 빌드할 수 있으며, 코드 삽입 공격에 의해 웹 응용 프로그램이 손상되는 경우 잠재적 피해를 제한할 수 있습니다.

아래 목록에는 각 신뢰 수준과 연관된 제한 사항이 나와 있습니다.

완전 신뢰 응용 프로그램은 모든 리소스 종류에 제한 없이 액세스할 수 있으며 권한 작업을 수행할 수 있습니다.
높은/보통/낮은/최소 신뢰 응용 프로그램은 비관리 코드 또는 서비스 구성 요소를 호출하거나 이벤트 로그에 기록하거나 메시지 큐의 큐 또는 OLE DB 데이터 원본에 액세스할 수 없습니다.
높은 신뢰 응용 프로그램은 파일 시스템에 제한 없이 액세스할 수 있습니다.
보통 신뢰 응용 프로그램은 파일 시스템에 제한적으로 액세스할 수 있으며 자체 응용 프로그램 디렉터리 계층 구조의 파일에만 액세스할 수 있습니다.
낮은/최소 신뢰 응용 프로그램은 SQL Server 데이터베이스에 액세스할 수 없습니다.
최소 신뢰 응용 프로그램은 어떤 리소스에도 액세스할 수 없습니다.

4.3. .NET 인증

인증을 통해 사이트와 응용 프로그램 액세스를 요청하는 클라이언트의 ID를 확인할 수 있습니다. 인증을 사용하도록 설정하면 IIS 8은 사용자가 제공한 계정 자격 증명을 사용하여 사용자에게 부여된 권한과 사용자가 액세스할 수 있는 리소스를 결정합니다.

이 섹션에서는 ASP.NET 응용 프로그램 관련 인증 모드에 대해 설명합니다.

ASP.NET 폼 인증
ASP.NET 가장 인증

ASP.NET 폼 인증

폼 인증에서는 클라이언트 쪽 리디렉션을 사용하여 인증되지 않은 사용자를 HTML 폼으로 전달합니다. 이 폼에서 사용자는 자격 증명(보통 사용자 이름과 암호)을 입력할 수 있습니다. 자격 증명이 확인되면 사용자는 원래 요청했던 페이지로 리디렉션됩니다. 폼 인증에서는 쿠키를 사용하여 서버 및 클라이언트 브라우저 간에 사용자 자격 증명을 전달하는 경우가 많습니다.

다음 섹션에서는 폼 인증을 사이트에 추가하려는 경우 확인해야 할 사항에 대해 설명합니다.

폼 인증 기본 사항
인증 쿠키

폼 인증 기본 사항

ASP.NET 폼 기반 인증은 많은 요청을 받는 공용 웹 서버의 사이트나 응용 프로그램에서 효율적으로 작동합니다. 이 인증 모드를 사용하는 경우 운영 체제에서 제공하는 인증 메커니즘에 의존하지 않고 응용 프로그램 수준에서 클라이언트 등록 및 인증을 관리할 수 있습니다.

중요

폼 인증에서는 사용자 이름과 암호를 일반 텍스트로 웹 서버에 보내므로 홈 페이지를 제외한 응용 프로그램의 다른 모든 페이지와 로그온 페이지에는 SSL(Secure Sockets Layer) 암호화를 사용해야 합니다. SSL에 대한 자세한 내용은 4.5를 참조하세요. TLS/SSL 통신.

폼 인증에서는 사용자가 ASP.NET 구성원 자격 데이터베이스의 ID를 사용하여 로그온할 수 있습니다. 이 인증 방법은 HTML 로그온 페이지로의 리디렉션을 통해 사용자의 ID를 확인합니다. 사이트 또는 응용 프로그램 수준에서 폼 인증을 구성할 수 있습니다.

폼 인증이 편리한 이유는 다음과 같습니다.

SQL Server 데이터베이스 또는 Active Directory와 같은 사용자 지정 데이터 저장소를 인증에 사용할 수 있습니다.
웹 사용자 인터페이스와 쉽게 통합할 수 있습니다.
클라이언트가 모든 브라우저를 사용할 수 있습니다.

권한 부여를 위해 구성원 자격 역할을 사용하려는 경우에는 폼 인증 또는 그와 비슷한 인증 방법을 사용합니다.

중요

폼 인증을 선택하는 경우에는 챌린지 기반 인증 방법을 동시에 사용할 수 없습니다.

기본적으로 폼 인증의 로그인 URL은 Login.aspx입니다. 사이트나 응용 프로그램을 방문하는 클라이언트용으로 고유한 로그인 페이지를 만들 수 있습니다. 예를 들어 방문자로부터 특정 정보를 수집하거나 사이트의 선택한 페이지 또는 선택한 응용 프로그램에 대한 구성원 자격을 제공할 수 있습니다.

폼 인증의 기본 제한 시간 값은 30초입니다. 세션 수명을 단축하고 쿠키 재생 공격 가능성을 줄이려는 경우 제한 시간 값을 더 짧게 변경할 수 있습니다.

인증 쿠키

인증 쿠키는 클라이언트에 응용 프로그램의 일부 또는 모든 페이지에 대한 액세스 권한이 있는지를 확인하는 토큰으로 사용됩니다. 반면 개인 설정 쿠키는 특정 사이트나 응용 프로그램의 사용자 환경을 결정하는 사용자별 설정을 포함합니다.

중요: 인증 쿠키는 모든 요청과 함께 클라이언트와 서버 간에 전달되므로 항상 SSL(Secure Sockets Layer)을 사용하여 인증 쿠키를 보호합니다. SSL에 대한 자세한 내용은 4.5를 참조하세요. TLS/SSL 통신.

쿠키는 리디렉션할 필요가 없으므로 쿼리 문자열에 비해 사이트 방문자를 추적하는 데 보다 효율적입니다. 그러나 쿠키는 브라우저별로 다르며 쿠키 사용을 지원하지 않는 브라우저도 있습니다. 또한 브라우저에서 쿠키 지원을 사용하지 않도록 설정하는 사용자도 있으므로, 쿠키 기반 인증을 사용하는 것이 항상 효율적이지는 않습니다.

기본적으로 ASP.NET 응용 프로그램의 쿠키 이름은 .ASPXAUTH입니다. 그러나 각 응용 프로그램에 대해 고유한 쿠키 이름과 경로를 대신 사용할 수 있습니다. 그러나 이렇게 하면 특정 응용 프로그램에 대해 인증된 사용자가 웹 서버의 다른 응용 프로그램에 대해서는 인증되지 않을 수 있습니다.

사이트 또는 애플리케이션에 대해 다음 쿠키 모드 중 하나를 선택할 수 있습니다.

Mode	Description
쿠키 사용	장치에 관계없이 쿠키를 항상 사용합니다.
쿠키 사용 안 함	쿠키를 사용하지 않습니다.
자동 검색	장치 프로필에서 쿠키를 지원하는 경우 쿠키를 사용하고 그렇지 않으면 쿠키를 사용하지 않습니다. 쿠키를 지원하는 것으로 알려진 데스크톱 브라우저의 경우 ASP.NET은 쿠키가 사용하도록 설정되어 있는지를 확인합니다. 이 설정은 기본값입니다.
장치 프로필 사용	장치 프로필에서 쿠키를 지원하는 경우 쿠키를 사용하고 그렇지 않으면 쿠키를 사용하지 않습니다. ASP.NET은 쿠키를 지원하는 디바이스에서 쿠키가 사용하도록 설정되어 있는지를 확인하지 않습니다. 이 설정은 IIS 8의 기본값입니다.

쿠키 보호 모드는 폼 인증 쿠키가 특정 응용 프로그램에 대해 수행하는 기능을 정의합니다. 다음 표에는 정의할 수 있는 쿠키 보호 모드가 나와 있습니다.

Mode	Description
암호화 및 유효성 검사	응용 프로그램이 데이터 유효성 검사 및 암호화를 모두 사용하여 쿠키를 보호하도록 지정합니다. 이 옵션에서는 컴퓨터 키를 기준으로 구성된 데이터 유효성 검사 알고리즘을 사용합니다. 3DES(Triple DES)를 사용할 수 있으며 키 길이가 충분하면(48바이트 이상) 암호화에 3DES가 사용됩니다. 이 설정이 기본값이자 권장 값입니다.
없음	개인 설정에만 쿠키를 사용하며 보안 요구 사항이 엄격하지 않은 사이트에 대해 암호화 및 유효성 검사를 모두 사용하지 않도록 지정합니다. 이 방식으로 쿠키를 사용하지 않는 것이 좋습니다. 그러나 .NET Framework를 통해 개인 설정을 사용하도록 설정할 때 이 방식을 사용하면 리소스가 가장 적게 사용됩니다.
암호화	Triple DES 또는 DES를 사용하여 쿠키를 암호화하되 쿠키에 대해 데이터 유효성 검사는 수행하지 않도록 지정합니다. 이 방식으로 사용하는 쿠키는 일반 텍스트 공격을 받을 수 있습니다.
유효성 검사	유효성 검사 체계가 암호화된 쿠키의 내용이 전송 중에 변경되지 않았는지를 확인하도록 지정합니다.

중요

암호화 및 유효성 검사 쿠키는 보안상 서로 분리해 두는 것이 좋습니다. 암호화 쿠키 도용이 유효성 검사 쿠키 도용보다 보안성 측면에서 더 위험합니다.

클라이언트가 자주 요청하는 개체를 포함하는 응용 프로그램의 경우 해당 개체를 캐시하면 응용 프로그램 성능을 개선할 수 있습니다. 인증 쿠키 시간이 초과되기 전에 사용자가 캐시된 개체에 액세스하는 경우 IIS 8을 사용하면 캐시된 개체가 캐시에 남아 있고 타이머가 다시 설정됩니다. 그러나 사용자가 해당 시간 동안 캐시된 개체에 액세스하지 않으면 IIS 8은 캐시된 개체를 캐시에서 제거합니다.

다음과 같은 상황에서는 이 설정을 사용하는 것이 좋습니다.

캐싱에 사용할 수 있는 메모리의 양이 제한되는 경우
캐시할 개체의 수가 많은 경우. 이 설정을 사용하면 가장 자주 요청되는 캐시만 캐시에 유지할 수 있습니다.

참고

인증 쿠키 시간이 초과될 때까지의 시간(분)은 인증 쿠키 시간 제한(분)에서 지정합니다.

ASP.NET 가장 인증

ASP.NET 응용 프로그램의 기본 보안 컨텍스트와는 다른 보안 컨텍스트에서 ASP.NET 응용 프로그램을 실행하려는 경우 ASP.NET 가장을 사용합니다.

ASP.NET 애플리케이션에 가장을 사용하도록 설정하는 경우 해당 애플리케이션은 IIS 8에서 인증된 사용자 또는 사용자가 설정한 임의의 계정으로 두 가지 컨텍스트 중 하나에서 실행할 수 있습니다. 예를 들어 익명 인증을 사용하며 인증된 사용자로 ASP.NET 응용 프로그램을 실행하도록 선택하는 경우 응용 프로그램은 익명 사용자용으로 설정된 계정(보통 IUSR)에서 실행됩니다. 마찬가지로 임의 계정에서 애플리케이션을 실행하도록 선택한 경우에는 해당 계정에 대해 설정된 보안 컨텍스트에서 애플리케이션이 실행됩니다.

ASP.NET 가장은 기본적으로 사용하지 않도록 설정됩니다. 가장을 사용하도록 설정하면 ASP.NET 애플리케이션이 IIS 8에서 인증된 사용자의 보안 컨텍스트에서 실행됩니다.

4.4. 컴퓨터 키 설정

컴퓨터 키를 사용하면 폼 인증 쿠키 데이터 및 페이지 수준 보기 상태 데이터를 보호할 수 있으며, out-of-process 세션 상태 식별도 확인할 수 있습니다. ASP.NET에서는 다음과 같은 유형의 컴퓨터 키를 사용합니다.

유효성 검사 키 - MAC(메시지 인증 코드)를 계산하여 데이터 무결성을 확인합니다. 이 키는 폼 인증 쿠키 또는 특정 페이지의 보기 상태에 추가됩니다.
암호 해독 키 - 폼 인증 티켓 및 보기 상태를 암호화하고 암호를 해독하는 데 사용됩니다.

IIS 8을 사용하면 유효성 검사 및 암호화 설정을 구성하고 보기 상태, 양식 인증, 멤버 자격, 역할 및 익명 식별과 같은 ASP.NET 애플리케이션 서비스에 사용할 머신 키를 생성할 수 있습니다.

응용 프로그램용 컴퓨터 키를 생성하기 전에 다음과 같은 디자인 관련 사항을 결정합니다.

사용할 유효성 검사 방법을 결정합니다. AES, MD5, SHA1(기본값), TripleDES, HMACSHA256, HMACSHA384 또는 HMACSHA512.
사용할 암호화 방법(자동(기본값), AES, TripleDES 또는 DES를 결정합니다.
런타임에 유효성 검사 키를 자동으로 생성할지 여부 결정
각 응용 프로그램에 대해 고유한 유효성 검사 키를 생성할지 여부 결정
런타임에 암호 해독 키를 자동으로 생성할지 여부 결정
각 응용 프로그램에 대해 고유한 암호 해독 키를 생성할지 여부 결정

4.5. TLS/SSL 통신

TLS(전송 계층 보안) 및 그 이전 버전인 SSL(Secure Sockets Layer)은 웹 사이트의 통신 보안 기능을 제공하는 프로토콜입니다. TLS/SSL을 사용하여 서버와 클라이언트를 인증한 다음 인증된 당사자 간에 메시지를 암호화할 수 있습니다.

인증 프로세스에서 TLS/SSL 클라이언트는 TLS/SSL 서버에 메시지를 보내고 서버는 서버가 자신을 인증하는 데 필요한 정보로 응답합니다. 클라이언트와 서버가 추가적인 세션 키 교환을 수행하고 인증 대화가 종료됩니다. 인증이 완료되면 인증 프로세스 중에 설정된 대칭 암호화 키를 사용하여 서버와 클라이언트 간에 SSL로 보호되는 통신을 시작할 수 있습니다.

웹 사이트에 대해 TSL/SSL을 구성하려면 다음을 수행합니다.

CA(인증 기관)에서 서버 인증서를 받습니다. 서버 인증서를 참조하세요.
사이트에 SSL 바인딩을 추가합니다. SSL 바인딩을 참조하세요.
사이트에서 SSL을 사용해야 하도록 IIS를 설정합니다. 사이트에서 SSL을 사용해야 하도록 설정을 참조하세요.
사이트에 대한 클라이언트 인증서 사용을 고려합니다. 클라이언트 인증서를 참조하세요.

서버 인증서

서버 인증서는 CA(인증 기관)에서 받을 수 있습니다. 인증 기관에서 서버 인증서를 받는 것은 SSL(Secure Sockets Layer) 또는 TLS(전송 계층 보안)를 구성하는 단계 중 하나입니다. 타사 CA에서 서버 인증서를 받을 수 있습니다. 타사 CA에서 인증서를 받는 경우 인증서 발급 전에 확인 증명을 제공해야 할 수 있습니다. Microsoft 인증서 서비스 등의 온라인 CA를 사용하여 자체 서버 인증서를 발급할 수도 있습니다.

디지털 인증서는 사용자나 컴퓨터의 ID를 확인하기 위한 온라인 암호와 같이 작동하는 전자 파일로, 클라이언트 통신에 사용되는 SSL로 암호화된 채널을 만드는 데 사용됩니다. 인증서는 CA(인증 기관)에서 발급하는 디지털 확인서로, 인증서 소유자의 ID를 보증하며 통신 당사자들이 암호화를 사용하여 안전한 방식으로 통신을 할 수 있도록 합니다.

디지털 인증서는 다음 작업을 수행합니다.

그들은 자신의 소유자 - 사람, 웹 사이트, 라우터와 같은 네트워크 리소스가 진정으로 누구 또는 무엇을 주장하는지 인증합니다.
온라인에서 교환되는 데이터의 도용 또는 변조를 방지합니다.

디지털 인증서는 타사 CA에서 발급되거나 Microsoft Windows PKI(공개 키 인프라)에서 인증서 서비스를 통해 발급될 수도 있고 자체 서명될 수도 있습니다. 각 인증서 유형에는 장단점이 있습니다. 각 유형의 디지털 인증서는 변조 방지 처리되어 있으며 위조할 수 없습니다.

인증서는 다양한 용도로 발급될 수 있습니다. 이러한 용도로는 웹 사용자 인증, 웹 서버 인증, S/MIME(Secure/Multipurpose Internet Mail Extensions), IPsec(인터넷 프로토콜 보안), TLS(전송 계층 보안), 코드 서명 등이 있습니다.

인증서는 공개 키를 포함하며 그에 해당하는 개인 키를 소유한 사용자, 컴퓨터 또는 서비스의 ID에 이 공개 키를 첨부합니다. 클라이언트와 서버는 공개 키 및 개인 키를 사용하여 데이터를 전송하기 전에 암호화합니다. Windows 기반 사용자, 컴퓨터 및 서비스의 경우 신뢰할 수 있는 루트 인증서 저장소에 루트 인증서의 복사본이 있고 해당 인증서에 유효한 인증 경로가 포함되어 있으면 CA에 신뢰가 설정됩니다. 해지되지 않았으며 유효 기간이 만료되지 않은 인증서만이 유효합니다.

SSL 바인딩

다양한 용도로 사용되거나 다른 프로토콜을 사용해야 하는 사이트 콘텐츠가 있으면 사이트에 여러 바인딩을 할당할 수 있습니다. 상거래 사이트의 응용 프로그램에서는 사용자가 상품을 구매하려면 계정에 로그온해야 하는 경우를 예로 들어 보겠습니다. 해당 회사는 HTTP에서 사이트를 호스팅하지만 사용자는 HTTPS 페이지에서 계정에 로그온해야 합니다. 이 예제에서 사이트에는 HTTP 부분과 HTTPS 부분에 하나씩 두 개의 바인딩이 있습니다.

IIS 관리자를 사용하여 HTTP 및 HTTPS 이외의 프로토콜에 대한 바인딩을 직접 추가할 수는 없습니다. WCF(Windows Communication Foundation)에서 지원하는 프로토콜 등의 다른 프로토콜에 대한 바인딩을 추가하려면 다른 관리 도구 중 하나를 사용합니다. 그러나 IIS FTP(파일 전송 프로토콜) 서버를 설치하는 경우에는 IIS 관리자를 사용하여 FTP 바인딩을 추가할 수 있습니다. UI를 확장하는 기타 모듈 또는 타사 기능을 다운로드할 수 있는 경우도 있습니다.

사이트에서 SSL을 사용해야 하도록 설정

SSL(Secure Sockets Layer) 암호화는 클라이언트와 서버 간에 전송되는 기밀 정보나 개인 정보를 보호합니다. SSL을 사용하도록 설정하면 원격 클라이언트는 https://로 시작하는 URL을 사용하여 사이트에 액세스합니다.

SSL 설정을 사용하도록 설정하려면 먼저 서버 인증서를 구성하고 HTTPS 바인딩을 만듭니다. 그런 후에 다음의 상황 중 하나 이상에서 SSL(Secure Sockets Layer) 암호화를 사용해야 하도록 설정합니다.

암호화된 채널을 통해 서버의 기밀 또는 개인 콘텐츠를 보호해야 하는 경우
사용자가 개인 정보를 전송하기 전에 서버의 ID를 확인할 수 있도록 하려는 경우
클라이언트 인증서를 사용하여 서버에 액세스하는 클라이언트를 인증하려는 경우

클라이언트 인증서

클라이언트가 웹 서버의 콘텐츠에 액세스하기 전에 해당 ID를 확인하려면 클라이언트 인증서를 구성합니다. 클라이언트 인증서는 기본적으로 무시됩니다.

웹 사이트에서 클라이언트 인증서를 구성하려면 먼저 서버 인증서를 구성하고 HTTPS 바인딩을 만들어 SSL(Secure Sockets Layer) 설정을 사용하도록 설정합니다.

모든 클라이언트의 ID를 확인하도록 하려면 해당 클라이언트 인증서를 반드시 사용하도록 지정합니다. 일부 클라이언트는 ID를 먼저 확인하지 않고 콘텐츠에 액세스할 수 있는 경우 해당 클라이언트 인증서가 허용되도록 지정합니다.

다음을 통해 공유