역할 보안
업데이트: 2007년 11월
역할 관리를 사용하면 "역할"이라는 범주를 만들어 응용 프로그램에 대한 권한 부여를 관리할 수 있습니다. 사용자를 역할에 할당하면 사용자 이름을 대신해서 또는 이름과 함께 역할에 따라 웹 응용 프로그램의 여러 다른 부분이나 기능에 대한 액세스를 제어할 수 있습니다. 예를 들어 직원 응용 프로그램에는 각 역할마다 서로 다른 권한이 지정되어 있는 관리자, 직원, 이사 등과 같은 역할이 있을 수 있습니다.
사용자는 둘 이상의 역할에 속할 수 있습니다. 예를 들어 토론 포럼 사이트의 경우 일부 사용자는 구성원 및 사회자 역할을 모두 맡을 수 있습니다. 역할마다 사이트에 대한 권한을 서로 다르게 정의할 수 있으며 두 가지 역할을 모두 맡은 사용자는 두 권한 집합을 모두 가지게 됩니다.
최선의 코딩 및 구성 방법을 따르면 응용 프로그램의 보안을 향상시킬 수 있지만 Microsoft Windows 및 IIS(인터넷 정보 서비스)용 최신 보안 패치를 비롯해 Microsoft SQL Server, Active Directory 또는 다른 역할 데이터 소스를 위한 모든 패치를 사용하여 응용 프로그램 서버를 항상 최신 상태로 유지하는 것도 중요합니다.
안전한 코드 작성 및 응용 프로그램 보안을 위한 최선의 방법에 대한 자세한 내용은 Michael Howard 및 David LeBlanc이 공동으로 저술한 책인 "Writing Secure Code"와 Microsoft Patterns and Practices(https://www.microsoft.com/resources/practices/default.mspx)에서 제공하는 지침을 참조하십시오.
보안 역할 관리자 구성
ASP.NET 응용 프로그램에서는 역할 관리자를 사용하지 않는 응용 프로그램의 보안을 향상시키기 위해 역할 관리자 기능이 기본적으로 비활성화되어 있습니다. 역할 관리자 기능을 활성화하면 기본 구성 설정은 가장 안전한 값으로 설정됩니다. 역할 관리자 구성 설정 및 기본값에 대한 내용은 roleManager 요소(ASP.NET 설정 스키마)를 참조하십시오.
구성 값 보안
응용 프로그램의 구성 파일에 중요한 정보를 저장할 때는 보호되는 구성을 사용하여 중요한 값을 암호화해야 합니다. 이 중에서도 특히 중요한 정보에는 machineKey 구성 요소에 저장되는 암호화 키와 connectionStrings 구성 요소에 저장되는 데이터 소스 연결 문자열이 포함됩니다. 자세한 내용은 보호되는 구성을 사용하여 구성 정보 암호화를 참조하십시오.
보안 암호화 키 및 해시
roleManager 요소의 cookieProtection 특성을 All로 설정하여 쿠키에 캐시되는 역할 이름을 보호하는 것이 좋습니다. 지정한 암호화 알고리즘의 암호화 키 값은 machineKey 구성 요소에 저장되어 있습니다. 강력한 암호화를 위해 선택한 암호화 알고리즘에 대해 적절한 길이의 임의로 생성된 값을 암호화 키로 지정합니다.
여러 응용 프로그램을 호스팅하는 서버에는 응용 프로그램마다 고유한 암호화 키를 정의해야 합니다. 이보다 다소 안전성이 떨어지는 대안은 단일 암호화 키를 정의하고 이 키를 사용해 IsolateApps 옵션을 지정하는 것입니다.
호스트 서버에서도 재정의 권한을 거부하여 컴퓨터 구성의 구성 설정을 재정의하는 기능을 제한할 수 있습니다. 여기에는 응용 프로그램의 Web.config 파일에 암호화 키를 다시 정의하는 기능을 거부하는 설정이 포함됩니다.
역할 데이터 소스 연결 보안
연결 문자열
앞에서 설명한 것처럼 SQL Server, Active Directory 또는 다른 데이터 소스 응용 프로그램에 액세스하는 데 사용하는 연결 문자열은 안전하게 보호해야 합니다. 데이터베이스 서버의 연결을 안전하게 유지하려면 보호되는 구성을 사용하여 구성의 연결 문자열 정보를 암호화해야 합니다. 자세한 내용은 보호되는 구성을 사용하여 구성 정보 암호화를 참조하십시오.
통합 보안을 사용하여 SQL Server에 연결
SQL Server를 실행하는 컴퓨터에 연결할 때는 통합 보안을 사용하여 연결 문자열이 손상되고 사용자 ID와 암호가 노출되는 일이 없도록 해야 합니다. 연결에 통합 보안을 사용하도록 지정하여 SQL Server를 실행하는 컴퓨터에 연결하면 역할 관리자 기능에 프로세스 ID가 표시됩니다. 응용 프로그램 풀과 같이 ASP.NET을 실행하는 프로세스 ID는 기본 프로세스 계정이거나 제한된 사용자 계정이어야 합니다. 자세한 내용은 ASP.NET 가장을 참조하십시오.
SQL Server 데이터베이스 권한
역할의 사용자 정보를 저장하는 데 사용하는 SQL Server 데이터베이스에는 사용자가 필요한 기능 및 표시에만 액세스하도록 제한할 수 있는 데이터베이스 역할 및 뷰가 포함되어 있습니다. SQL Server 역할 데이터베이스에 연결하는 데 필요한 사용자 ID에는 최소한의 권한을 할당해야 합니다. 자세한 내용은 SQL Server용 응용 프로그램 서비스 데이터베이스의 역할 및 뷰를 참조하십시오.
SQL Server Express 작업자 프로세스 ID
SQL Server Express 2005에는 연결 사용자의 ID로 작업자 프로세스의 실행을 시작할 수 있는 새 작업 모드가 포함되어 있습니다. 이 기능을 "다음 사용자 이름으로 실행" 모드라고 합니다. 이 작업 모드는 IIS를 사용하는 데스크톱 개발에 적합하지만 신뢰할 수 없는 여러 고객 코드베이스를 호스팅하는 웹 서버에서는 작업자 프로세스를 시작하지 않는 것이 좋습니다. 서로 신뢰하지 않는 응용 프로그램이 포함된 공유 호스팅 서버는 "다음 사용자 이름으로 실행" 기능을 명시적으로 해제해야 합니다. SQL Express 인스턴스에 연결하고(예:osql –E –S .\sqlexpress) 다음 Transact-SQL 명령을 실행하면 이 기능을 해제할 수 있습니다.
EXEC sp_configure 'show advanced option', '1'
GO
RECONFIGURE WITH OVERRIDE
GO
EXEC sp_configure 'user instances enabled', 0
GO
RECONFIGURE WITH OVERRIDE
GO
권한 부여 저장소 보안
AuthorizationStoreRoleProvider를 사용할 때 데이터 소스의 보안을 향상시키려면 파일 기반의 권한 부여 저장소와 달리 역할 정보를 Active Directory 서버에 저장해야 합니다. 이렇게 하면 웹 서버의 보안이 침해될 경우 정책 저장소 파일이 노출되지 않도록 할 수 있습니다.
Active Directory 서버에 연결하면 역할 관리자 기능에 프로세스 ID가 표시됩니다. 응용 프로그램 풀과 같이 ASP.NET을 실행하는 프로세스 ID는 기본 프로세스 계정이거나 제한된 사용자 계정이어야 합니다. 자세한 내용은 ASP.NET 가장을 참조하십시오. 또한 ASP.NET 응용 프로그램에서 요구하는 특정 권한 부여 관리자 응용 프로그램 또는 범위에 대해서만 액세스를 허용하도록 Active Directory 권한 부여 저장소의 계정에 권한을 할당해야 합니다.
Active Directory 서버의 연결을 보호하려면 IPSec(Internet Protocol Security) 같은 네트워크 암호화 도구를 사용해야 합니다.
역할 쿠키 보안
roleManager 요소의 cacheRolesInCookie 특성을 true로 설정하면 사용자의 역할 이름이 세션 쿠키에 캐시되도록 지정하여 성능을 향상시킬 수 있습니다. 기본적으로 역할 이름은 암호화된 형식으로 저장되지만 cookieRequireSSL 특성을 true로 설정하여 역할 쿠키에 대해 추가 보안을 제공하고 SSL이 활성화되어 있을 때만 세션 쿠키에 역할을 캐시해야 합니다. 이렇게 하면 역할 쿠키가 네트워크를 통해 노출되고 응용 프로그램의 정보 누출에서 사용되는 것을 막을 수 있습니다.
응용 프로그램 간의 쿠키 공유 차단
roleManager 요소의 cacheRolesInCookie 특성을 true로 설정하고 cookiePath 특성을 여러 응용 프로그램이 포함된 경로로 설정하면 동일한 역할 쿠키가 여러 응용 프로그램에 전달됩니다. 각 응용 프로그램에 대해 machineKey 구성 요소의 암호화 정보를 동일하게 지정하면 여러 응용 프로그램 간에 역할 쿠키를 공유할 수 있습니다.
여러 응용 프로그램 간에 역할 이름 쿠키를 공유하지 않으려면 응용 프로그램마다 machineKey 구성 요소의 암호화 키를 개별적으로 지정하고 각 응용 프로그램의 cookiePath 특성을 특정 응용 프로그램 경로로 설정하며 ApplicationName 속성을 응용 프로그램마다 고유한 값으로 설정합니다.
역할을 사용하는 보안 웹 페이지
로그온 페이지 같이 중요한 데이터를 사용하는 응용 프로그램 페이지는 표준 웹 보안 메커니즘을 사용하여 보호해야 합니다. SSL(Secure Sockets Layer)을 사용하는 등의 방법으로 이러한 페이지를 보호할 수 있으며, 이때 사용자 정보 업데이트나 사용자 삭제 같은 중요한 작업을 수행하려면 로그온해야 합니다.
또한 페이지에 암호 및 사용자 이름 같은 중요한 기능 데이터가 일반 텍스트로 노출되어서는 안 됩니다. 이러한 정보를 표시하는 페이지는 SSL을 사용하고 인증된 사용자만 사용할 수 있도록 해야 합니다. 또한 중요한 기능 데이터를 쿠키에 저장하거나 안전하지 않은 연결을 통해 보내지 않도록 합니다.
서비스 거부 공격으로부터 보호
업데이트 또는 크기가 큰 검색 연산을 수행하는 메서드를 여러 클라이언트가 동시에 호출하면 역할 데이터 소스의 응답성이 떨어질 수 있습니다. 서비스 거부 공격에 대한 노출을 줄이려면 데이터베이스 업데이트 또는 검색 메서드를 사용하는 ASP.NET 페이지에는 관리 권한이 있는 사용자만 액세스할 수 있도록 제한하고 일반적인 용도로 유효성 검사 및 역할 멤버 자격을 제공하는 ASP.NET 페이지만 노출합니다.
오류 메시지 및 이벤트
예외
중요한 정보가 원하지 않는 소스로 노출되지 않도록 하려면 응용 프로그램에서 자세한 오류 메시지를 표시하지 않거나 클라이언트가 웹 서버일 경우에만 자세한 오류 메시지를 표시하도록 구성합니다. 자세한 내용은 customErrors 요소(ASP.NET 설정 스키마)를 참조하십시오.
이벤트 로그
서버에서 Windows Server 2003을 실행 중인 경우 이벤트 로그를 보호하고 이벤트 로그의 크기, 보존 등과 관련된 매개 변수를 설정하여 간접적인 서비스 거부 공격을 막음으로써 응용 프로그램의 보안을 향상시킬 수 있습니다.
추적 정보
역할 관리자 기능과 관련된 특정 동작이 발생하면 이를 추적하여 추적 정보를 로그 파일에 저장하도록 웹 서버를 구성할 수 있습니다. 추적 로그 파일에는 사용자 이름 및 역할 이름 같은 중요한 정보가 저장될 수 있으므로 추적 로그 파일의 위치를 구성하고 추적 로그 파일에 액세스하는 기능을 비롯하여 추적 활성화 기능에 대한 액세스를 관리자로 제한해야 합니다.
사용자 지정 역할 공급자
사용자 지정 역할 공급자를 만들 때는 최선의 보안 방법에 따라 데이터베이스를 작업할 때 SQL 주입 공격 등의 공격을 피해야 합니다. 또한 사용자 지정 역할 공급자를 사용할 때는 최선의 보안 방법으로 공급자를 검토했는지 확인합니다.
Culture의 영향을 받는 문자 사용
SQL Server 역할 공급자나 사용자 지정 역할 공급자를 사용하는 경우 culture 구분 형식으로 역할 데이터를 저장하도록 데이터 소스를 구성할 수 있습니다. 그러나 ASP.NET에서는 권한 부여 구성 요소에 지정된 역할 이름과 데이터 소스의 역할 이름을 평가할 때 항상 culture를 고려하지 않습니다. 따라서 권한이 없는 역할 이름을 culture 고정으로 취급하는 경우 해당 이름이 권한이 있는 역할의 이름과 동일하게 취급되어 권한이 없는 사용자가 권한을 부여받을 수 있습니다. 권한이 없는 사용자가 무단으로 액세스하지 못하게 하려면 culture 고정으로 평가할 때 역할 이름이 고유해야 합니다.