SQL Server Security Drilldown

Presentation on theme: "SQL Server Security Drilldown"— Presentation transcript:

1 SQL Server Security Drilldown
SQL 2000 Technical Workshop 강사:최 인규

2 Agenda 보안 위협의 환경변화 DB 보안 위협 환경의 전개 DB 보안: 논점 SQL 보안 권고 강건한 구현 기본 보안
문서화 Securing SQL Server 보안을 고려한 설치 구성 보안 모니터링 Customer Tools Recommended periodic scans Multi-tier scenarios: SQL Server in the Enterprise Best Practices for Applications Over SQL

3 보안 위협의 환경 변화 10년전의 데이터베이스: 물리적으로 보안 분산되지 않았고 중앙의 데이터센터의 보관
고객서비스 담당부서, 구매 관리자등을 통해 내부적으로 접근 보안에 관련된 문제가 거의 보고 되지 않았다. 현재의 데이터베이스는 외부에서 접근하는 것이 많아지고 있다.: 공급자가 직접 연결 고객이 직접 연결 고객과 파터너가 데이터를 공유 데이터는 응응프로그램에서 가장 귀한 자원이다. 데이터는 통합되거나 집계되어질때 값어치가 증가 데이터가 도난되고 변경되거나 파괴되는 기회는 증가 데이터베이스 보안문제의 증가: 2001년 1월 101 DB alerts -- 두개의 데이터베이스 이슈 SANS/FBI top 20 list –

4 DB Security: 논점 스토리지와 데이터를 관리하는 비용의 감소 경쟁적인 요구조건
대부분의 응용프로그램의 가치는 지속적인 데이터에 있다. 회사나 조직 심지어는 개인의 데이터도 다른 사람에게도 가치를 지니고 있다. 정보는 많은 산업분야에서 가장 귀중한 자산이 되고 있다. 경향을 분석하거나 이해를 할 때는 순간적인 데이터도 중요한 가치를 지닌다. 스토리지와 데이터를 관리하는 비용의 감소 경쟁적인 요구조건 가치가 있는 곳에는 그것을 필요로 하는 사람이 있다. 보안위협의 환경 변화에는 데이터베이스도 포함된다. “Port 1433 [SQL Server] regularly registered as one of the top scan ports in the Internet Storm Center” –Source:

5 Agenda 보안 위협의 환경변화 DB 보안 위협 환경의 전개 DB 보안: 논점 SQL 보안 권고 강건한 구현 기본 보안
문서화 Securing SQL Server 보안을 고려한 설치 구성 보안 모니터링 Customer Tools Recommended periodic scans Multi-tier scenarios: SQL Server in the Enterprise Best Practices for Applications Over SQL

6 SQL 보안 권고 위협적인 환경의 변화에 대한 응답: 높은 우선순위를 두고 보안 문제를 다루는 결정이 요구됨 보안 권고:
3달 동안 보안 작업에 전념하라. 잠재적인 보안 이슈를 격리하여 초점을 맞추어야 할때가 왔다. Core SQL Server engineering value: 보안과 데이터 무결성은 타협에 의해 결코 열어두어서는 안된다. 팀간의 상호 노력이 필요

7 강건한 구현 이슈에 대한 이해 모든 팀 구성원들의 보안 훈련 개발자와 테스터들에게 특별한 교육
보안 전무가와 다른 팀들간의 공동 작업- 보안 이슈를 더 잘알기위해 분야를 나누어 해결하라. 구성요소의 경계를 분명히 정하고 각 구성요소의 위험 수준을 인식 위협 분석 구성요소 별 위협 분석 구성요소의 기능과 인터페이스, 상호작용을 분석 절충 가능한가? 데이터의 흐름은? 절충은 다른 종류의 위협을 야기할수 있다. Escalation of privileges; tampering of data; spoofing; information disclosure; code injection

8 강건한 구현 Code Reviews: 모든 소스파일의 세밀한 리뷰(review) 코드 리뷰 검사목록 개발
직접적인 코드 리뷰—위협 분석에 기반한 일반적인 파일 리뷰—top down 접근 코드 리뷰 검사목록 개발 일반적인 이슈의 가이드라인제시 Tools support: 자동화된 도구들로 일반적인 문제를 찾아낸다. 가정의 유효성을 확신하기 위해 코드의 의존상태를 추적한다. 오류를 줄이고 생산성을 높인다.

9 기본 보안 Secure defaults for all configuration options
보안 구성을 취약하게 하는 선택하기 어렵게 하기 기본 세팅은 보안을 잘되어 있다. 최소한의 권한을 부여 기능을 수행하기 위한 최소권한 부여 개체들에 적당한 기본 퍼미션 부여 권한의 상향 조정 금지 필요한 구성요소만 설치 선택적 구성요소들을 무조건 설치해서는 안됨

10 문서화 샘플 코드의 안전과 보안을 위해 문서화 보안 권고 공백 패스워드 가장 좋은 보안 습관 특정 가이드 라인
Documentation focus on security continues White papers and guides Best Practices document (to be released soon) 보안검사 목록(Security checklist)

11 Agenda 보안 위협의 환경변화 DB 보안 위협 환경의 전개 DB 보안: 논점 SQL 보안 권고 강건한 구현 기본 보안
문서화 Securing SQL Server 보안을 고려한 설치 구성 보안 모니터링 Customer Tools Recommended periodic scans Multi-tier scenarios: SQL Server in the Enterprise Best Practices for Applications Over SQL

12 보안을 고려한 설치 물리적인 보안 관계되는 시스템,미디어,백업본등 보호하라 방화벽으로 데이터베이스를 보호
S/W mediating database access Install on NTFS file system 물리적인 파일을 보안 가급적이면 서비스를 격리하라 적은 권한의 서비스 계정을 사용하라 Do not choose LocalSystem, box admin or domain admin Cracked DB won’t get access to rest of enterprise 가장최근의 코드가 가장 보안된 코드이다. Apply latest service packs and security patches

13 구성 옵션 인증모드 윈도우 통합 인증 More Secure Protocols (Kerberos and NTLM)
Kerberos allows for delegation Allows for password policy enforcements Typically does not require app storing passwords If using Mixed mode (Standard SQL Auth) Always use SSL to encrypt at least the login packets Use strong passwords Never Set blank passwords 로깅 감사 Audit failed login attempts at the very least 분산 쿼리 제한(ad hoc queries) Choose static ports for named instances Avoid opening UDP1434 at firewall

14 Secure Operation Understand the security model 필요시에만 기능을 구성하고 작동시켜라.
Security White Paper for SQL 2000 Security White Paper for SQL 7.0 Security section of SQL Server 2000 Operations Guide 필요시에만 기능을 구성하고 작동시켜라. Replication, Agent, SQL MAIL etc Xp_cmdshell 사용 기본 퍼미션을 변경하지 말것 proxy account 로administrator을 사용해서는 안됨 가급적이면 작은 관리자 그룹 구성 Don’t put all enterprise/box admins in one group 서비스 계정의 변경 Use Enterprise Manager KB article Q 시스템 카탈로그 직접수정 금지

15 Secure Operation 백업을 포함한 미디어보안
Assume damage possible and have aggressive backup policy Test disaster recovery system 적당한 수중의 감사 최소한의 중요한 사용자 행위 예: sysadmin actions, server role membership changes, password changes, login related activity etc. Keep overhead minimum 암호화( Encryption) options Protect sensitive data over the wire Use SSL, IPSEC etc 파일 수준 암호화(encryption) Prevents illicit copying of database files SQL supports Encrypted File System Third party support: 데이터 암호화

16 Monitoring SQL ‘Health’
Microsoft Baseline Security Analyzer Graphical and command line tool 로컬시스템이나 리모트 시스템 스탠 가능 취약점을 스캔: Windows IIS and SQL server 현재 시스템의 구성의 보안 수준을 확인 SQL Server 검사 Blank SA passwords, file and registry permissions, number of sysadmins, exposure of xp_cmdshell to non sysadmins, etc.. Version 1.1은 다중 인스턴스를 지원

17 Monitoring SQL ‘Health’
공백 패스워드를 가진 계정을 찾고 제거 사용하지 않는 계정 제거 public에게 퍼미션이 부여된 개체 스캔 Verify login-user mapping Interesting in attach/detach scnearios Sp_change_users_login with report option Enumerate membership in privileged roles Ensure membership to trusted individuals only Ensure start-up procedures are safe and trusted 파일과 레지스트리 퍼미션을 확인 Ensure passwords not present in install files Run Killpwd utility

18 Agenda 보안 위협의 환경변화 DB 보안 위협 환경의 전개 DB 보안: 논점 SQL 보안 권고 강건한 구현 기본 보안
문서화 Securing SQL Server 보안을 고려한 설치 구성 보안 모니터링 Customer Tools Recommended periodic scans Multi-tier scenarios: SQL Server in the Enterprise Best Practices for Applications Over SQL

19 멀티 티어 시나리오들 미들티어에서 백엔드로 연결을 할때 세가지 가능한 옵션들
가능하면 사용자 정보를 저장하지 말것 (문자열로 사용자 로긴ID와 패스워드를 하드코딩하지 말라.) 가능하면 보안 인증 프로토콜을 사용 ex.커버로스5 세가지 가능한 옵션들 오리지날 호출자 정보를 데이터베이스에 보내기 단일 윈도우즈 문맥을 데이터베이스에 보내기 SQL 인증을 사용하여 단일 연결을 데이터베이스에 보내기 Consider IIS, to ASP.NET talking to SQL IIS ASP.NET SQL

20 호출자 문맥 보내기 모든 컴퓨터들은 단일 또는 신뢰된 도메인에 있어야 한다. 엑티브 디렉토리(AD)가 요구됨
커브러스와 위임(delegation)이 활성화 되어있어야 함 ASP.NET에서 대리(Impersonation)가 반드시 활성화되어야 한다. 서비스는 위임(delegation)에 대해 신뢰해야 함 장점: 모든 보안은 SQL Server에서 강제된다. 모든 사용자 액션들에 대해 모든 감사를 할 수 있다. 단점: Extranet가 Internet 시나리오들에 대해 항상 적용될 수는 없다. 연결 풀링이 제한된다. 오리지날 호출자들은 연결을 공유할 수 없다.

21 DB에 대한 단일 응용프로그램 문맥(윈도우즈)
ASP.NET을 낮은 권한의 계정으로 실행 최종 사용자가 응용프로그램 레벨에서 인증 DB는 응용프로그램이 사용자를 인증하는 것을 신뢰 ASP.NET 계정의 문맥에서 생성된 DB 연결 낮은 권한의 도메인 계층 사용 다른 방법으로, SQL Server가 실행되는 컴퓨터 윈도우즈의 로컬 계정과 동일한 사용자 이름과 패스워드 사용 비 신뢰된(Non-trusted) 도메인에 대해 연결이 생성될 경우 유용 SQL에서 계정은 단지 필요한 실행시의 권한만 가짐 높은 권한의 계정이 아님; sysadmin 아님 장점: 증명서(Credentials)를 위한 저장소 필요 없음 증명서를 SQL에 직접 전달할 필요 없음 낮은 권한 계정으로 실행됨, 타협에 의한 잠재적 손해 최소화 단일 계정이 사용되기 때문에 연결 풀링이 가능

22 DB에 대한 단일 응용프로그램 문맥(Std. SQL)
최종 사용자는 응용프로그램 레벨에서 인증 DB는 사용자를 인증하는 응용프로그램을 신뢰 표준 SQL 로그인과 패스워드를 사용하는 DB 연결 낮은 권한의 로그인 계정 사용 강력한 패스워드 사용 네트웍에서 SSL을 통해 인증 보호 강화 데이터 보호 API들을 사용하는 미들 티어에서 보안 증명서(Secure Credentials) 서비스의 증명서를 사용하여 암호화 단지 동일한 서비스 계증만이 암호 해독 단점: 증명서 저장소가 요구됨 표준 SQL 인증은 윈도우즈 인증보다 약함 장점: 방화벽과 비 신뢰된(Non-trusted) 도메인에서 동작 연결 풀링 가능

23 Agenda 보안 위협의 환경변화 DB 보안 위협 환경의 전개 DB 보안: 논점 SQL 보안 권고 강건한 구현 기본 보안
문서화 Securing SQL Server 보안을 고려한 설치 구성 보안 모니터링 Customer Tools Recommended periodic scans Multi-tier scenarios: SQL Server in the Enterprise Best Practices for Applications Over SQL

24 Application Best Practices
약한 액세스 계정 사용 단지 응용플로그램을 실행하기 위해 필요한 액션들 정도 관리를 위해서는 다른 계정 사용 SQL 인증 보다는 윈도우즈 인증 사용 보안 구현이 쉬움 패스워드 저장소 필요없음 만일 SQL 인증을 사용할 경우, SSL 사용 민감한 데이터에 대해 암호화 설정 권한 허가와 소유권에 대해 역할(roles) 사용 관리의 용이 역할에 의해 소유된 개체들은, 사용자가 드롭(drop)될 때 같이 드롭되거나 이름이 변경될 필요가 없음 Public 그룹에 대해 권한 허가를 부여하지 말것 개발자 수준의 에러 메세지를 사용자들에게 보여주지 말것 다중 단계 공격에서 침입자에게 정보를 누설할 수 있음

25 Using Ownership Chaining
뷰나 저장프로시저를 이용하여 스키라를 숨겨라. 퍼미션을 관리하기 위해 ownership chainin를 사용하라. Ownership Chaining: If calling object and caller object have same owner; permissions check skipped on called object Example: Create table user1.t1 (c1 int not null) Create proc user2.proc1 as select * from user1.t1 return If user3 has execute permissions on proc1, still need select permissions on user1.t1 Execute Perms checked for User3 Select Perms checked for User3 User2.Proc1 User1.T1 User3 User1.Proc1 User1.T1 Execute Perms checked for User3 NO Perms checked for User3

26 Preventing SQL Injection(주입)
Class of attack where attacker can insert or manipulate queries made by application to backend Example: APPLICATION CODE var shipcity; ShipCity = Request.form (“Shipcity”) var sql = “SELECT * FROM OrdersTable WHERE ShipCity = ‘” + Shipcity + “’”; GOOD USER Inputs Redmond in the form Query to backend is: SELECT * FROM OrdersTable WHERE ShipCity = ‘Redmond’ MALICIOUS USER Inputs the following in the form: Redmond’ DROP TABLE OrderTable – Query to the backend is: DROP TABLE OrdersTable—’

27 SQL Injection Why SQL injection works? 연결이 더 높른 권한이 있는 계정으로 연결될때
프로그램이 정해지지 않은 입력을 받아들일때 Mitigating(완화하다) SQL Injection 사용자의 모든입력의 유효성을 검사해라. Define set of valid input, accept only that Reject all invalid input 저장프로시저에서 dynamic SQL를 피하라. 프로그램에서 최소한의 권한을 이용하여 접속하라 Sysadmin를 사용해서는 안된다.

28 개발 부서를 위한 팁 다양한 보안 이슈를 이해해야 한다. 공격 시나리오
다양한 이슈(SQL injection, cross site scripting, buffer overflow attacks) 구성요소화 하고 위협을 분석한다. 구성요소의 경계 평가 구성요소의 기능과 인터페이스, 상호작용을 분석 절충 가능한가? 데이터의 흐름은? 절충은 다른 종류의 위협을 야기할수 있다. Escalation of privileges; tampering of data; spoofing; information disclosure; code injection Code Review 개발자 코드 리뷰 검사 목록 일반적인 보안 이슈를 위한 가이드라인 직접적인 코드 리뷰—위협 분석에 기반한 일반적인 파일 리뷰—top down 접근

29 © 2002 Microsoft Corporation. All rights reserved.
This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.