프로덕션에서 특권을 줄이지 만 과업을 지나치게 어렵게하지 않는 것에 대한 조언

Windows 2008 R2에서 SQL Server 2005 및 2008 실행

우리는 개발자를 위한 프로덕션 권한을 줄이려고합니다 . 그리고 DBA와 같은 방식 으로 제작 권한을 제한하고 필요할 때 권한을 높이고 싶습니다 .

저의 주요 목표는 DBA가 만든 어리석은 실수를 제거하는 것입니다. 개발자는 프로덕션 환경에서 최대한 읽기 액세스 권한을 갖습니다. 우리는 실수를 할 수 없지만 항상 생산 권한을 갖지 않는 슈퍼 히어로처럼 행동하고 싶어합니다.

가장 좋은 방법은 무엇입니까? 일상적으로 설치하는 동안 가장 고통스러운 것은 무엇입니까?

현재 모든 서버 및 데이터베이스에 대한 권한이있는 DBA 용 Windows 그룹이 있습니다.

또한 OS / 원격 로그인 권한을 낮추는 데 관심이 있지만 DB 권한이 가장 중요합니다.

우리는 추적을 sa로 실행하고 이전 로그인의 SA 권한을 제거하기 전에 일부 소유권 정리를 위해 높은 권한이 필요하다고 생각합니다. 다른 문제는 무엇입니까?

당신의 조언과 경험을 공유해 주셔서 감사합니다!

이상적으로 운영 프로덕션 데이터베이스의 경우 개발자가 서버 또는 서버의 데이터베이스에 전혀 액세스하지 못하도록해야합니다. 이런 종류의 일은 SOX 준수를 위해 가장 먼저해야 할 일 중 하나입니다 .

사용자 아이디 아래에 실행하는 것이 권리의 종류를 들어, 유일한 권리는 그들이 진짜로해야 db_datareader, db_datawriter및 명시 적 GRANT EXECUTE ON x TO y(각 저장된 프로 시저 및 사용자 정의 함수에 대한 x사용자 아이디에 대한 y).

프로덕션 환경에서 트레이스를 실행해야하는 경우 몇 가지 문제가 있으며이를 설명하려면 Great Wall of Text ™가 필요합니다. 첫 번째 권장 사항은 프로덕션과 마찬가지로 QA 환경을 잠그고 추적을 실행해야하는 경우 prod db의 백업을 QA로 복원하고 추적을 실행하는 것입니다. 또한 SOX, HIPAA 또는 PCI-DSS 요구 사항이있는 경우 QA로 복원하기 전에 prod 데이터를 더 잘 소독해야합니다.

현재 모든 서버 및 데이터베이스에 대한 권한이있는 DBA 용 Windows 그룹이 있습니다.

로그온 권한을 부여하고 데이터 권한을 확인하십시오. 그러나 DBAly 업무를 수행하려면 상승 된 권한으로 별도의 로그인을 사용하십시오. 나는 이것을 수행하는 한 금융 고객을 알고 있습니다. 정식 Windows 인증 기반 로그인은 실수로 할 수있는 피해가 제한되었습니다. 별도의 SQL 인증 로그인으로 DML을 복원하고 실행해야합니다.

내가 일한 한 정부 기관은 각 서버 / DB 관리자마다 2 개의 별도 로그인을 사용했습니다. 따라서 Tangurena내 도메인 로그인 인 경우 (이 로그인에는 일반 User권한이 있음) TangurenaAdmin별도의 Administrator로그인이됩니다. 당신이 당신의 관리자를 사용하는 경우 모든 시간 계정 문제로 얻을 수 있지만, 그때는 다른 것들에 대한 권한이 부족 (NO 이메일처럼. 오, 당신 말은 나쁜 일처럼 ... 그 ).

내가 현재 일하고있는 정부 기관에는 각 서버 / DB 관리자가 표준 사용자보다 높은 권한을 가지고 있지만 관리자는 아닙니다 ( PowerUser그룹 으로 생각하십시오 ). 도메인 관리자 기능은 공유 도메인 관리자 계정으로 수행됩니다.

일반적인 오류는 프로덕션 서버에서 복원 된 QA와 같은 잘못된 데이터베이스를 복원하는 것이므로 제한된 권한이나 여러 로그인을 통해 해결되지 않습니다. 잠재적으로 파괴적인 것을 쌍으로하는 것은 위험을 최소화하는 한 가지 방법입니다.

나는 우리가 추적을 실행하기 위해 높은 개인이 필요하다고 생각합니다.

아니요. ALTER TRACE 권한 만 필요합니다 :
http://msdn.microsoft.com/en-us/library/ms187611.aspx

처음에는 액세스를 일정 시간 동안 제거해도 문제가없는 개발 또는 QA 환경에서 모든 권한 재생을 수행하는 것이 좋습니다. 응용 프로그램에 보안 관련 문제가 없는지 확인해야합니다.

내부 접근 방식을 알려 드리겠습니다.

• 모든 응용 프로그램은 데이터베이스 (일반적으로 db_owner 데이터베이스 역할)에 필요한 권한이 부여 된 단일 도메인 사용자를 사용합니다.

• 가끔 데이터를 읽을 때는 SQL 로그인을 사용합니다. 해당 사용자에게 데이터베이스 역할-db_datareader를 할당합니다. 여기서는 기본 데이터베이스 클러스터에서 개발자의 액세스를 종료합니다. 다른 아이디어로는 자정에 완료된 주 서버 데이터베이스의 복사본 (로그 전달을 사용하여 수행) 인보고 서버 데이터베이스를 사용합니다. 킬러 애드혹 쿼리로보고 서버를 종료하지 않기 위해 메모리 및 CPU에 자원 그룹 할당을 사용합니다.

• DBA 팀의 경우 머신과 서버 (Windows 머신의 관리자 및 SQL 서버의 sysadmin)에 대한 모든 권한이있는 도메인 그룹이 있습니다.

• 설치를 위해 업데이트를 실행할 때 사용하는 데이터베이스에 db_owner 인 SQL 사용자가 있습니다. 스키마 변경을 모니터링하기 위해 DDL 트리거를 사용하며 설치 중에 또는 별도의 변경으로 수행 된 변경을 확인해야합니다.

• 숙련 된 개발자에게는 가끔 예외가 있지만 필요가 충족되면 액세스를 제거합니다. 도메인 로그인을 기반으로 권한을 받으므로 추적 / ddl보기에서 연결을 모니터링하고 ddl 트리거로 가능한 변경 사항을 모니터링 할 수 있습니다.

서버 보안 폴더의 Management Studio에서 로그인 및 사용자와 함께 작동하는 모든 작업을 수행하는 데 필요한 모든 로그인을 만든 다음 데이터베이스와 연결하고 필요한 역할을 부여합니다. 작업을 스크립팅하면 처음에는 서버 로그인이 생성되고 해당 로그인에 연결된 데이터베이스 사용자가 생성 된 다음 해당 사용자에 대한 데이터베이스 역할이 할당 된 것을 볼 수 있습니다. 스크립트 세트에 스크립트를 보관할 수 있으므로 어떤 사용자가 살아 있고 발로 차지 않아야하는지 여부를 확인할 수 있습니다.

SQL Server에서 데이터베이스 사용자를 작성하고 database role읽기 / 쓰기 / 소유 권한 으로 데이터베이스 사용자를 지정할 수 있습니다 . 사용자가 프로덕션으로 마이그레이션되면 마이그레이션 된 데이터베이스 사용자로 이동하여 원하지 않는 역할을 선택 취소 할 수 있습니다. 예를 들어, 사용자 스탠이 테스트중인 db_owner (데이터베이스의 소유권)의 구성원이라고 가정하십시오. 사용자 스탠이 프로덕션으로 마이그레이션되면 db_owner에서이를 가져 와서 db_datareader (읽기 전용)의 역할 만 할당 할 수 있습니다.

SQL 2005+에서는을 사용하여보다 세밀한 제어가 가능합니다 schema. 자세한 내용은 스키마 에서이 링크 를 확인 하십시오.