데이터베이스 애플리케이션을 연결, 식별, 쿼리, 배포 계층에서 보호합니다. 성공적인 인증은 연결이 서버를 검증하기 위해 전송 계층 보안(TLS)을 사용했는지, 또는 해당 신원이 애플리케이션이 필요한 권한만 가졌다는 것을 증명하지 않습니다.
보안 체크리스트
| Area | 조치 |
|---|---|
| 네트워크 암호화. | 호환되는 엔드포인트에서는 Encrypt=true 또는 Encrypt=Strict를 사용하고, 원격 프로덕션 연결에는 TrustServerCertificate=false를 유지하세요. |
| 인증. | 대상과 호스트가 지원할 경우 Windows 통합 인증, 관리 신원 또는 워크로드 신원을 선호합니다. |
| 권한 부여 | 필요한 데이터베이스 권한만 부여하세요. 스키마 배포와 애플리케이션 요청에는 별도의 아이덴티티를 사용하세요. |
| 쿼리 구성. | 데이터 값을 매개변수화하세요. 애플리케이션 제어 허용 목록에서 매개변수가 될 수 없는 식별자를 선택하세요. |
| 연결 설정. | 신뢰할 수 있는 엔드포인트 구성을 사용 SqlConnectionStringBuilder 하세요. 사용자가 제어하는 연결 문자열 조각을 연결하지 마세요. |
| 비밀 | 보호된 비밀 저장소나 호스트 신원을 사용하세요. 비밀번호, 개인 키, 또는 베어러 토큰은 절대 커밋하지 마세요. |
| 풀링. | 신원 선택은 특히 토큰 콜백의 경우 풀 키와 일관되게 유지하세요. |
| 오류와 진단. | 안전한 애플리케이션 오류를 반환하고 자격 증명이나 토큰 없이 제한된 진단 정보를 유지할 수 있습니다. |
| 유지보수. | 업데이트는 드라이버 및 신원 라이브러리 의존성을 지원하며, 업그레이드 후 연결 및 인증 동작을 수행합니다. |
인증서 오류에 대응하여 설정을 변경하기 전에 암호화 및 인증서 검증 을 참조하세요.
TrustServerCertificate=true 신원 확인을 제거하며; 인증서 배포를 해결하지는 않습니다.
일반적인 위협
신뢰할 수 없는 입력이 데이터베이스 명령어와 연결 설정에 어떻게 도달하는지, 각 작업을 수행하는 신원이 무엇인지, 그리고 어떤 진단 정보가 서비스를 떠나는지 검토하세요.
SQL 인젝션
SQL 인젝션은 애플리케이션이 신뢰할 수 없는 입력을 데이터 대신 실행 가능한 Transact-SQL(T-SQL)로 처리할 때 발생합니다. 값에 대해 명시적인 타입과 적절한 크기를 가진 명령어 매개변수를 사용하세요. 비즈니스 규칙에 대해서도 입력값을 검증하세요.
저장 프로시저가 신뢰할 수 없는 입력을 동적 SQL에 연결하면 주입을 막지 못합니다. 적절한 경우 동적 sp_executesql 문장을 매개변수화하세요. 테이블 이름, 열명 또는 정렬 방향이 달라져야 한다면, 애플리케이션 제어 허용 목록에서 선택하세요; 일반 값 매개변수는 SQL 식별자나 문법을 대체할 수 없습니다.
임의의 원시 SQL을 안전하게 만들기 위해 인용 탈출, 연결 문자열 빌더, 객체-관계형 매핑 도구에만 의존하지 마세요. 명령 및 매개변수 및 보안이 강화된 동적 SQL 작성을 참조하세요.
권한 상승
가장 권한이 낮은 데이터베이스 신원으로 애플리케이션 요청을 실행하세요. 애플리케이션 오류를 사라지게 하기 위해 서버 관리자나 데이터베이스 소유자에게 권한을 부여하지 마세요.
스키마 마이그레이션 자격 증명은 런타임 자격 증명과 분리하세요. 필요한 테이블이나 프로시저에 적합한 역할을 통해 접근 권한을 부여합니다. 운영이 발신자의 권한을 넘어서는 권한이 필요할 때만 인증서 서명이나 신중하게 범위 설정된 사칭을 사용하고, 그 경계는 별도로 검토하세요.
인증은 애플리케이션 승인이 아닙니다. 서비스가 여러 사용자에게 하나의 데이터베이스 신원으로 연결되더라도, 각 사용자가 접근할 수 있는 레코드와 작업을 강제해야 합니다.
검색 및 지능적 관찰
신뢰할 수 없는 클라이언트에게 원시 데이터베이스 예외 세부사항, 연결 문자열, 스택 트레이스를 반환하지 마세요. 적절한 경우 애플리케이션 수준의 오류와 상관관계 식별자를 반환하세요.
진단 기록을 제한된 로그 시스템에 보관하세요. 연산, SqlClient 오류 번호, 재시도 시도, 상관관계 식별자 등의 정보를 기록하세요. 쿼리 텍스트, 매개변수 값, 엔드포인트 또는 개인 데이터에 대한 예외 텍스트와 추적 설정을 검토하여 수집하거나 내보내기 전에 반드시 검토하세요.
오류를 명시적으로 처리하세요. 실패한 쿼리나 인증 시도를 빈 데이터로 성공 응답으로 전환하지 마세요. 인증서 실패, 무효 자격 증명, 허가 거부 등은 무제한 재시도가 아니라 수정이 필요합니다.
인증
애플리케이션 호스트에 적합한 아이덴티티를 사용하세요. Windows 인증에는 SQL 암호를 저장할 필요가 없습니다. Azure 호스팅 워크로드는 지원되는 경우 관리 신원을 사용할 수 있으며; 연합 호스트는 워크로드 아이덴티티를 사용할 수 있습니다. 인터랙티브 인증은 무인 서비스가 아니라 사용자를 위한 것입니다.
연결 문자열 값을 할당하는 데 사용됩니다 SqlConnectionStringBuilder . 값을 올바르게 인용하고 이스케이프하지만, 목적지는 승인하지 않습니다. 서버, 데이터베이스, 인증 모드, TLS 정책을 애플리케이션 또는 관리자 관리 하에 두세요.
신뢰할 수 없는 요청이 Encrypt, Authentication, TrustServerCertificate 또는 임의의 서버 주소를 선택하지 못하게 하세요. 멀티테넌트 애플리케이션의 경우, 요청에서 완전한 연결 문자열을 받아들이기보다는 권한 있는 테넌트 구성을 해결하세요.
SQL Server 및 Windows 인증, Microsoft Entra 인증도 참고하세요.
암호
SQL 인증이나 클라이언트 시크릿 자격 증명이 필요할 때는 보호된 구성이나 시크릿 저장소에서 시크릿을 가져옵니다. 읽기 접근을 제한하고, 비밀을 순환하며, 배포 후 오래된 자격 증명을 제거하세요.
환경 변수는 주입된 비밀을 담을 수 있지만, 비밀 저장소가 아니며 프로세스 진단이나 배포 도구로 노출될 수 있습니다. 이를 인쇄하거나 사고 보고서에 포함시키지 마세요. 개발 비밀은 소스 컨트롤에서 벗어나게 하세요.
기본값인 Persist Security Info=false 그대로 두세요. 이 설정은 열린 연결의 connection-string 속성에 대한 노출을 제한합니다; 원래 설정 문자열을 지우거나 기록한 비밀을 보호하지는 않습니다.
액세스 토큰 및 연결 풀링
연결 풀은 인증된 물리적 연결을 재사용합니다. 각 풀을 의도한 보안 컨텍스트와 연관시키세요.
- 리터럴
AccessToken은 풀 키에 포함됩니다. SqlClient는 그 속성으로 갱신하거나 만료 시점을 추론할 수 없습니다. 토큰 수명을 관리하고 필요에 따라 영향을 받는 풀을 정리하세요. -
AccessTokenCallback는 풀 키에 포함됩니다. 풀을 공유해야 할 연결은 안정적인 대리자와 자격 증명 인스턴스를 재사용하세요. - 동일한 콜백 입력에 대해 동일한 식별자를 반환합니다. 풀 입력값이 해당 ID를 일관되게 격리하도록 보장되지 않는 한, 공유 콜백 내부에서 현재 웹 사용자의 ID를 읽지 마세요.
- 접근 토큰, 클라이언트 비밀, 인증서 개인 키, 완전한 자격 증명 연결 문자열은 절대 기록하지 마세요.
토큰 콜백 가이드라인을 활용해 인수 및 갱신을 실행하세요. 토큰 콜백은 TLS 인증서 검증을 맞춤화하지 않습니다.
배치 및 서비스 경계
지원되는 Microsoft 릴리스를 사용하세요. Data.SqlClient 및 인증 라이브러리를 사용하세요. 드라이버가 제공하는 Microsoft Entra 모드를 사용할 때는 핵심 드라이버와 Azure 확장 버전 모두를 정렬하세요. 서버의 인증서 구성과 실제 인증 흐름에 대한 업그레이드를 테스트하세요, 단순히 연결 문자열 파싱뿐만 아니라요.
가능한 한 데이터베이스를 공용 네트워크에서 멀리하고, 애플리케이션이 요구하는 엔드포인트에 대한 접근을 제한하세요. TLS는 전송 중인 트래픽을 보호합니다; 데이터베이스 권한을 강제하거나 디스크 내 데이터베이스 파일을 암호화하지 않습니다.
LocalDB는 Windows 개발 도구입니다. 파일을 보호하고, 원격 TLS나 Microsoft Entra 행동의 증거로 LocalDB 전용 실행을 사용하지 마세요.
SQL Server 기능을 도입하기 전에 목적지의 기능을 확인하세요. Microsoft Fabric의 SQL 데이터베이스는 Microsoft Entra 신원을 필요로 하며, SQL 로그인, 애플리케이션 역할, 또는 항상 암호화된 테이블을 지원하지 않습니다. Fabric SQL 데이터베이스 제한 사항을 참조하세요.
이 섹션의 내용
Write Dynamic SQL 은 동적 문장을 매개변수화하고 실행 권한을 검토하는 방법을 설명합니다.