개요: 이 기사에서는 주로 ASP.NET WEB 응용 프로그램의 보안 모델 유형을 소개하고 장점과 단점을 비교하며 선택 메커니즘을 제안합니다.
키워드: 보안 모델 신뢰할 수 있는 하위 모델 시뮬레이션/위임 하위 모델 ASP.NET 웹 애플리케이션
1. 서문
ASP.NET 웹 응용 프로그램은 일반적으로 다중 계층 아키텍처에 속합니다. 일반적으로 논리 구조는 프레젠테이션 계층, 비즈니스 논리 계층 및 데이터 액세스 계층으로 나눌 수 있습니다. 응용 프로그램 리소스에 액세스하려면 클라이언트의 ID 인증 및 권한 부여가 여러 계층에 걸쳐 있어야 합니다. 수준. 이 문서에서는 주로 SP.NET 애플리케이션의 리소스 액세스 보안 모델에 대해 설명합니다.
2. 리소스 액세스 식별
웹 애플리케이션이 클라이언트에게 외부적으로 제공하는 일반적인 리소스에는
웹 페이지, 웹 서비스, 정적 리소스(HTML 페이지 및 이미지)와 같은 웹 서버 리소스가 포함됩니다.
사용자별 데이터 또는 애플리케이션 수준 데이터와 같은 데이터베이스 리소스.
원격 파일 시스템 리소스 등의 네트워크 리소스
레지스트리, 이벤트 로그, 구성 파일 등의 시스템 리소스
클라이언트는 각 계층을 통해 흐르는 ID를 사용하여 애플리케이션 계층 전체에서 이러한 리소스에 액세스합니다. 리소스 액세스에 사용되는 이 ID는 다음으로 구성됩니다.
원래 호출자의 ID 원래 호출자의 ID를 얻은 후 시스템의 각 계층을 통해 흐릅니다.
프로세스 ID 로컬 리소스 액세스 및 다운스트림 호출은 현재 프로세스 ID를 사용하여 이루어집니다. 이 접근법의 타당성은 대상 시스템에서 프로세스 정체성을 인식해야 하기 때문에 넘어야 할 경계에 따라 달라집니다. 이는 다음 두 가지 방법 중 하나로 호출되어야 합니다.
동일한 Windows 보안 도메인 내의 Windows 보안 도메인 간 - 트러스트 및 도메인 계정을 사용하거나 트러스트 관계가 존재하지 않는 경우 중복된 사용자 이름 및 비밀번호를 사용하십시오.
서비스 계정 이 접근 방식은 (고정) 서비스 계정을 사용합니다. 예를 들어 데이터베이스 액세스의 경우 서비스 계정은 데이터베이스에 연결된 구성 요소에 의해 고정된 SQL 사용자 이름과 비밀번호로 표시될 수 있습니다.
고정된 Windows ID가 필요한 경우 엔터프라이즈 서비스 서버 응용 프로그램을 사용해야 합니다.
사용자 지정 ID를 사용할 수 있는 Windows 계정이 없으면 Iprincipal 및 Identity를 사용하여 보안 컨텍스트에 대한 세부 정보를 포함할 수 있는 고유한 ID를 구성할 수 있습니다.
3. 자원 접근 모델
3.1 신뢰할 수 있는 하위 시스템 모델
그림 1에서 볼 수 있듯이 이 모델에서는 원래 호출자의 보안 컨텍스트가 운영 체제 수준의 서비스를 통해 흐르지 않지만 중간 서비스 계층에서 고정 ID를 사용하여 다운스트림 서비스 및 리소스에 액세스합니다. 신뢰할 수 있는 하위 시스템 모델은 다운스트림 서비스(예: 데이터베이스)가 호출자에게 권한을 부여하기 위해 업스트림 서비스를 신뢰한다는 사실에서 그 이름을 얻었습니다. 그림 1의 예에서 데이터베이스는 중간 계층에 의한 호출자의 인증을 신뢰하고 인증된 호출자만 신뢰할 수 있는 ID를 사용하여 데이터베이스에 액세스하도록 허용합니다.
3.1.1 리소스 접근 모드
신뢰할 수 있는 하위 시스템 모델에서 리소스 액세스 모델은 다음과 같습니다.
사용자 인증 사용자를 역할에 매핑 역할 멤버십을 기반으로 권한 부여 고정된 신뢰할 수 있는 ID를 사용하여 다운스트림 리소스에 액세스
3.1.2 고정식별
프로세스 ID 또는 미리 설정된 Windows 계정 서비스 계정을 사용하여 제공될 수 있는 다운스트림 시스템 및 리소스 관리자에 액세스하는 데 사용되는 고정 ID입니다. SQL Server 탐색기의 경우 이는 SQL Server에 대한 Windows 인증을 의미합니다.
프로세스 ID를 사용할 때 일반적으로 ASP.NET 프로세스 ID를 사용합니다(기본값은 ASPNET 계정). 실제 응용 프로그램에서는 ASPNET 계정을 보다 안전한 암호로 변경하고 ASP.NET 프로세스 계정과 일치하는 SQL Server 컴퓨터에 Windows 계정을 만들어야 하는 경우가 많습니다. 구체적인 방법은 다음과 같습니다.
%windr%Microsoft.NETFrameworkv1.1.4322CONFIG 디렉터리에 있는 Machine.config 파일을 편집하고 <processModel> 요소의 비밀번호 특성을 기본값으로 다시 구성합니다. <!-UserName="machine" 비밀번호 = "AutoGenerate" --><!-UserName="machine" 비밀번호="NewPassword" -->로 변경하거나 ASPNET_setreg.exe 도구를 사용하여 사용자 이름과 비밀번호를 레지스트리에 저장하고 구성을 다음과 같이 변경합니다. < !- 활성화="true" UserName="레지스트리:HKLMSOFTWAREYourAPPprocesssModelASPNET_SETREG,userName" 비밀번호=" 레지스트리:HKLMSOFTWAREYourAPPprocesssModelASPNET_SETREG,password " -->
다른 응용 프로그램은 지정된 SQL 계정(연결 문자열의 사용자 이름과 암호로 지정)을 사용하여 SQL Server에 액세스합니다. 이 경우 SQL 인증을 위해 데이터베이스를 구성해야 합니다. 구성 파일에 저장된 연결 문자열은 암호화로 보호되어야 합니다.
3.2 시뮬레이션/위임 모델
그림 2에 표시된 것처럼 가장/삭제 모델을 사용할 때 서비스 또는 구성 요소(일반적으로 논리적 비즈니스 서비스 계층에 위치)는 운영 체제 가장 기능을 사용하여 다음 다운스트림 서비스에 액세스하기 전에 클라이언트 ID를 가장합니다. 서비스가 동일한 시스템에 있는 경우 가장을 사용하는 것으로 충분하고, 다운스트림 서비스가 원격 시스템에 있는 경우 위임도 사용해야 하며, 다운스트림 리소스 액세스의 보안 컨텍스트는 클라이언트의 컨텍스트입니다.
3.3 자원 접근 모델 선택
두 가지 리소스 액세스 모델의 비교는 표 1에 나와 있습니다.
신뢰할 수 있는 하위 시스템 모델 시뮬레이션/위임된 모델 감사 기능의 백엔드는 상위 계층 서비스를 신뢰합니다. 중간 계층이 손상되면 백엔드 리소스가 공격에 취약해집니다. 백엔드 서비스는 우수한 보안을 통해 각 호출자를 인증하고 권한을 부여할 수 있습니다.
확장성은 연결 풀링을 지원하며 확장성이 좋습니다. 연결 풀링을 지원하지 않으며 확장성이 낮습니다.
백엔드 ACL 관리 ACL은 단일 엔터티용으로 구성되므로 관리 작업이 덜 필요합니다. 각 사용자에게 해당 액세스 수준을 부여해야 합니다. 백엔드 리소스 및 사용자 수가 증가하면 관리 작업이 번거로워집니다.
기술적인 문제를 위임할 필요가 없습니다. 위임이 필요합니다. 대부분의 보안 서비스 제공업체는 위임을 지원하지 않습니다.
신뢰할 수 있는 하위 시스템 모델은 대부분의 인터넷 응용 프로그램은 물론 대규모 인트라넷 응용 프로그램에도 사용됩니다. 주로 이 모델이 확장성을 잘 지원할 수 있기 때문입니다. 시뮬레이션/대리자 모델은 소규모 시스템에서 사용되는 경향이 있습니다. 이러한 응용 프로그램의 경우 확장성은 주요 고려 사항이 아니며 감사입니다.