보안 데이터 액세스
보안 ADO.NET 코드를 쓰려면 내부 데이터 저장소 또는 데이터베이스에서 사용할 수 있는 보안 메커니즘을 알아야 합니다. 또한, 애플리케이션에 포함될 수도 있는 다른 기능이나 구성 요소의 보안 문제도 고려해야 합니다.
인증, 권한 부여 및 사용 권한
Microsoft SQL Server에 연결하는 경우에는 Windows 인증, 즉 소위 말하는 통합 보안을 사용할 수 있습니다. 이 경우 사용자 ID와 암호가 전달되는 것이 아니라 현재 활성 Windows 사용자의 ID가 사용됩니다. Windows 인증은 온-프레미스 데이터베이스에 대해 권장되는 방식이며, 이는 사용자 자격 증명이 연결 문자열에 노출되지 않기 때문입니다. Windows 인증을 사용하여 SQL Server에 연결할 수 없는 경우에는 런타임에 연결 문자열을 만들기 위해 SqlConnectionStringBuilder을(를) 사용하는 방법을 고려해 보세요.
Important
사용 가능한 가장 안전한 인증 흐름을 사용하는 것이 권장됩니다. Azure SQL에 연결하려는 경우, 권장되는 인증 방법은 Azure 리소스에 대한 관리 ID입니다.
인증에 사용되는 자격 증명은 애플리케이션의 종류에 따라 다르게 처리해야 합니다. 예를 들어, Windows Forms 애플리케이션에서는 인증 정보를 입력하라는 메시지가 표시되거나 사용자의 Windows 자격 증명이 사용될 수 있습니다. 그러나 웹 애플리케이션의 경우 주로 사용자 입력을 통해서가 아닌 애플리케이션에서 제공하는 자격 증명을 사용하여 데이터에 액세스합니다.
인증된 후 사용자가 수행할 수 있는 작업의 범위는 각자에게 부여된 권한에 따라 다릅니다. 항상 최소 권한의 원칙에 따라 꼭 필요한 권한만 부여해야 합니다.
자세한 내용은 다음 리소스를 참조하세요.
| 리소스 | 설명 |
|---|---|
| 연결 정보 보호 | 보호되는 구성을 사용하여 연결 문자열을 암호화하는 것과 같이 연결 정보를 보호하는 기술과 최상의 보안 방법에 대해 설명합니다. |
| 연결 문자열 작성기 | 런타임에 사용자 입력을 기반으로 연결 문자열을 만드는 방법에 대해 설명합니다. |
| SQL Server 데이터베이스 엔진 및 Azure SQL Database에 대한 보안 | 보안 및 보호에 대한 정보를 Azure SQL Database 및 SQL Server 데이터베이스 엔진에서 찾기 위해 도움이 되는 링크를 제공합니다. |
매개 변수화된 명령 및 SQL 삽입
매개 변수화된 명령을 사용하면 공격자가 SQL 문에 명령을 “삽입”하여 서버의 보안을 손상시키는 SQL 삽입 공격을 막을 수 있습니다. 매개 변수화된 명령에서는 외부 소스에서 가져온 값이 Transact-SQL 문의 일부가 아닌 값으로만 전달되도록 하여 SQL 삽입 공격으로부터 보호합니다. 따라서 값에 삽입된 Transact-SQL 명령이 데이터 소스에서 실행되지 않으며 매개 변수 값으로만 평가됩니다. 매개 변수화된 명령은 이러한 보안상의 장점뿐만 아니라 Transact-SQL 문과 함께 전달되거나 저장 프로시저에 전달되는 값을 구성할 수 있는 편리한 방법을 제공합니다.
매개 변수화된 명령 사용에 대한 자세한 내용은 다음 리소스를 참조하세요.
| 리소스 | 설명 |
|---|---|
| DataAdapter 매개 변수 | DataAdapter와 함께 매개 변수를 사용하는 방법에 대해 설명합니다. |
| 저장 프로시저로 데이터 수정 | 매개 변수를 지정하고 반환 값을 가져오는 방법에 대해 설명합니다. |
| 저장 프로시저(데이터베이스 엔진) | 다양한 유형의 저장 프로시저 및 저장 프로시저 사용의 이점에 대해 설명합니다. |
검색 공격
공격자는 흔히 예외에서 얻은 서버, 데이터베이스, 테이블 이름 등의 정보를 사용하여 시스템에 대한 공격을 준비합니다. 예외에는 애플리케이션이나 데이터 소스에 대한 특정 정보가 포함될 수 있으므로 클라이언트에 꼭 필요한 정보만 노출함으로써 애플리케이션 및 데이터 소스를 보다 안전하게 보호할 수 있습니다.
자세한 내용은 다음 리소스를 참조하세요.
| 리소스 | 설명 |
|---|---|
| .NET의 예외 처리 및 Throw | try/catch/finally 구조적 예외 처리의 기본 형태에 대해 설명합니다. |
| 예외에 대한 모범 사례 | 최상의 예외 처리 방법에 대해 설명합니다. |
Excel 데이터 소스 및 Microsoft Access 보호
보안 요구 사항이 최소 수준이거나 없는 경우 Microsoft Access와 Microsoft Excel을 ADO.NET 애플리케이션의 데이터 스토리지로 사용할 수 있습니다. 두 프로그램의 보안 기능으로 어느 정도의 저지 효과는 볼 수 있지만 무분별한 사용자의 악의적인 장난을 막는 것 이상의 효과는 기대할 수 없습니다. Access 및 Excel의 실제 데이터 파일은 파일 시스템에 존재하며 모든 사용자가 액세스할 수 있습니다. 따라서 파일을 복사하거나 변경하기가 쉬워 도난이나 데이터 손실을 야기하는 공격에 취약합니다. 강력한 보안이 필요한 경우에는 파일 시스템에서 실제 데이터 파일을 읽을 수 없는 SQL Server나 다른 서버 기반 데이터베이스를 사용해야 합니다.
엔터프라이즈 서비스
COM+에는 Windows 계정 및 프로세스/스레드 가장을 사용하는 고유의 보안 모델이 포함되어 있습니다. System.EnterpriseServices 네임스페이스에서는 ServicedComponent 클래스를 통해 .NET 애플리케이션에서 관리 코드를 COM+ 보안 서비스와 통합할 수 있도록 하는 래퍼를 제공합니다.
비관리 코드와의 상호 운용
.NET Framework는 다양한 운영 체제 서비스, 외부 형식 라이브러리, COM+ 서비스, COM 구성 요소 등을 비관리 코드와의 상호 작용을 위해 제공합니다. 비관리 코드를 사용하려면 관리 코드에 대한 보안 경계 외부로 나가야 합니다. 코드와 코드를 호출하는 다른 코드 모두에 비관리 코드 권한(SecurityPermission 플래그가 지정된 UnmanagedCode)이 있어야 합니다. 비관리 코드로 인해 애플리케이션에 의도하지 않았던 보안상 취약한 부분이 생길 수 있습니다. 따라서 꼭 필요한 경우가 아니면 비관리 코드와의 상호 운용 작업은 피하는 것이 좋습니다.
자세한 내용은 비관리 코드 상호 운용을 참조하세요.