모든 사람이 sa 로그인을 사용하도록 허용하는 것이 왜 나쁜 습관입니까?

Microsoft조차도 SQL Server 인증 모드 사용을 권장하지 않지만 응용 프로그램에는 필요합니다.

saWindows 인증을 사용하고 해당 계정 (또는 계정 그룹)에 sysadmin 권한을 허용하는 대신 사용자가 직접 로그인을 사용하지 못하게하는 것이 가장 좋습니다 .

• 본질적으로 같은 것이 아닌가? 장점 / 단점은 무엇입니까?
• 모범 사례는 어떻게 SQL Server 인스턴스의 보안을 강화합니까?
• 프로덕션 인스턴스 또는 내부 개발 인스턴스에만 적용됩니까?

여기에 몇 가지 다른 질문이 있으므로 개별적으로 두드립니다.

"Windows 인증을 사용하는 대신 사용자가 sa 로그인을 직접 사용하지 못하게하는 것이 가장 좋습니다."

여기서 SA의 개념과 SQL 인증 및 Windows 인증의 개념을 혼합합니다.

SQL 인증은 모든 SQL Server에 저장되는 사용자 이름 및 암호 목록입니다. 그것이 SQL에 저장되어 있다는 사실이 첫 번째 문제입니다. 로그인 비밀번호를 변경해야하는 경우 모든 서버에서 비밀번호를 변경하거나 다른 서버에서 다른 비밀번호를 유지해야합니다. Windows 인증을 사용하면 로그인을 중앙에서 비활성화하고, 암호를 변경하고, 정책을 설정하는 등의 작업을 할 수 있습니다

SQL 인증을 사용하기로 선택한 경우 SA는 하나의 SQL 인증 로그인입니다. 관리자가 Windows 인증에있는 것처럼 기본 관리자 사용자 이름입니다. 하나의 인스턴스에는 로컬 슈퍼 파워가 있지만 모든 인스턴스에서 글로벌 슈퍼 파워는 아닙니다.

"... 그 계정 (또는 계정 그룹)에 sysadmin 권한을 허용합니다."

어떤 인증 방법을 선택하든 이상적으로는 최소 권한의 원칙을 따르고 자합니다. 즉, 사람들에게 업무를 수행하는 데 필요한 최소한의 권한 만 부여하면됩니다.

그것들을 단순한 로그인이라고 생각하지 마십시오-그들은 당신을 해고 할 수있는 사람들입니다. 데이터베이스를 삭제하거나 실수로 백업 작업을 비활성화하면 기본적으로 SQL은 누가 무엇을했는지 추적하지 않기 때문에 해고되지 않습니다. 당신은 그것이 일어나기 때문에 해고 될 사람이고, 어떤 사람이 그 일을했는지 ​​말할 수 없을 것입니다.

"모범 사례는 어떻게 SQL Server 인스턴스의 보안을 강화합니까?"

두 가지 일을하고 싶습니다 :

1. 사람들이 서버를 침입하지 못하도록 차단
2. 그들이 서버를 깨뜨릴 때, 누가 그 서버를했는지 정확하게 식별 할 수 있어야합니다

첫 번째는 최소한의 권한으로 사람들에게 필요한 권한 만 부여하고 더 이상 아무것도 제공하지 않는 것입니다.

두 번째는 공유 로그인을 허용하지 않고 (모든 사람이 동일한 사용자 이름 / 비밀번호를 사용하도록 허용하는 것과 같이) 이상적으로 로그인을 감사함으로써 각 사람에게 고유 한 로그인을 제공함으로써 달성됩니다. 아마도 마지막 부분은 고통스럽기 때문에 즉시 수행하지 않을 것입니다.하지만 조각을 먼저 배치하여 누군가 데이터베이스를 삭제하고 나중에 상사가 이유를 알고 싶어하는 경우 나중에 감사를 추가 할 수 있도록하십시오.

귀하의 생각을 알고 있습니다. "하지만 우리는 앱을 코딩하고 있으며 앱에 로그인이 필요합니다." 예, 애플리케이션에 자체 로그인을 제공하면 개발자는 해당 비밀번호를 알아야하지만 해당 로그인에는 올바른 사용 권한을 가진 사람이 없어야하는 권한이 없어야합니다. 예를 들어, db_datareader 및 db_datawriter 역할에만 있어야 할 수도 있습니다. 이렇게하면 데이터를 삽입, 업데이트, 삭제 및 선택할 수 있지만 스키마 변경, 인덱스 추가, 저장 프로 시저 변경 등은 아닙니다.

"이것은 프로덕션 인스턴스 또는 내부 개발 인스턴스에만 적용됩니까?"

나는 사람들이 물건을 깨뜨리는 것에 대해 보통 걱정하기 때문에 개발 인스턴스에도 그와 같이 많이 적용된다고 생각합니다. 사람들은 개발에서 서버를 깨는 것을 좋아합니다. 물론 프로덕션으로 마이그레이션하기 위해 변경 사항 목록을 묶을 때 특정 인덱스가 실제로 앱에 중요한지 또는 일부 헤드가 데이터베이스 튜닝 관리자를 실행하여 모든 변경 사항을 적용하도록 지시했는지 알아야합니다. . 적절한 권한은 그러한 고통을 줄이는 데 도움이됩니다.

실제로이 백서를 읽는 경우 : SQL Server Separation of Duties 백서

그것이 당신을 말할 것이다 아무도 자신의 계정에 시스템 관리자 권한을 사용하여야한다. 일일 액세스 계정에는 명시적인 sysadmin 권한이 아닌 최소 액세스 권한이 부여되어야합니다. CONTROL SERVER는 실제로 sysadmin에 가깝고 필요하지 않은 곳에서는 여전히 액세스를 거부 / 취소 할 수 있습니다. IT 컴플라이언스 표준을 충족해야하는 경우 누구에게나 sysadmin 권한을 허용하는 것이 문제가됩니다. 대부분의 표준은 최소한 sysadmin 역할을 사용해야합니다.

OS에서 기본 제공 관리자 계정으로하는 것처럼 "sa"계정을 비활성화하고 이름을 바꿉니다. 비상시에만 사용하십시오.

개발자에게는 일반적으로 개발 환경에 대한 전체 액세스 권한이 부여됩니다. 그런 다음 프로그램을 프로덕션 전 인스턴스로 이동하면 액세스 권한이 최소이거나 없어야합니다. 생산중인 것처럼 말입니다. 그것은 완벽한 세상입니다. 그러나 당신이 거기에 있지 않고 개발자가 당신이 필요로하는 것보다 더 높은 특권을 가지고 있다면, 나는 그들의 계정에서 감사를 감사합니다. 나는 그들이하는 모든 것과 모든 것을 어느 정도 포착 할 것입니다. 따라서 프로덕션 서버에있을 때 문제가 발생하는 경우 돌아가서 정확히 무엇을했는지 확인할 수 있습니다.

외부 규제 제어 또는 표준 (SOX, PCI 등)의 적용을받는 경우

• 감사에 실패합니다
• 월별 PCI 검사에서 실패

개발자는 개발을 위해서만 네트워크 SQL Server에 db_owner가 있어야합니다.

SQL Server가 모두 표준 빌드 (예 : 동일한 서비스 계정)로 네트워크에있는 경우 sa는 하나의 서버에 대한 모든 권한을 부여합니다.

서비스 계정이 로컬 관리자 인 경우 개발자도 서버를 완전히 제어 할 수 있습니다.

장점은 없습니다.

sa = sysadmin

sa로 로그인하면 사용자가 다음을 모두 수행 할 수 있습니다.-데이터베이스 삭제 및 작성-데이터베이스에서 오브젝트 수정-로그인 삭제 및 작성-비밀번호 변경-모든 데이터 삭제

Windows 계정 sysadmin 권한을 부여하면 동일한 작업을 수행합니다.

이 목록은 계속되지만 관리자가 아닌 사람이 sa를 사용하지 않아야하는 몇 가지 이유가 있습니다.

앱을 작동시키는 데 필요한 최소한의 권한으로 Windows 또는 SQL 계정을 만들어야합니다. (예 : 로그인, 저장 프로 시저 및 뷰에 액세스)

가장 좋은 방법은 강력한 암호를 입력하고 잊어 버리는 것입니다.

SA 계정이 약한 이유에 대해서는 두 가지 옵션이 있습니다. SA에 대해 암호가 약하거나 비어있는 경우 한 명의 악한 사람 ( '친절한 동료'로 번역)은 다음을 수행 할 수 있습니다.

• xp_cmdshell 시스템 프로 시저를 활성화하고 Sql Server 서비스 계정의 권한을 사용하여 로컬 상자에 파일을 손상시킵니다 (파일 만들기 / 제거). SA의 보안 수준이 낮다는 것은 실제로 인스턴스 설정에 대해 많은 것을 말하지는 않지만 서비스 사용자가 나쁜 관행을 따를 수 있음을 암시 할 수 있습니다 (예 : admin :-)).

• 인스턴스에서 메일을 활성화하고 작은 스팸 재미 스크립트를 빨리 전달합니다 (인터넷 제공 업체 또는 동료와 문제가 생길 수 있습니다. (메일의 위치에 따라 ;-));

데이터베이스, 로그인 등을 삭제할 수 있다는 명백한 사실은 지적하지 않습니다.

• 본질적으로 같은 것이 아닌가? 장점 / 단점은 무엇입니까?

• 반드시 그런 것은 아닙니다. 예를 들어 랩톱의 SQL Server 인스턴스에서 Windows 인증과 SQL 인증의 차이점은 이론적으로 외부 인증자는 자신의 도메인 외부에서 Windows 인증을 사용할 수 없기 때문에 외부 공격자가 SQL 계정 만 사용할 수 있음을 의미합니다. 계정. 사용자는 커피를 마시는 쇼핑몰에서 이웃 랩톱을 스캔 할 수 있으며 SQL 인스턴스가 설치되어 시작된 것을보고 무료로 즐거운 시간을 보낼 수 있습니다. 그것은 종종 일어날 수있는 것이 아닙니다 ...하지만 가능성이 있습니다 :-).

• 모범 사례는 어떻게 SQL Server 인스턴스의 보안을 강화합니까?

• 이 세상의 모든 모범 사례는 그 일을 수행합니다.. 그렇지 않으면 발생할 수있는 가능한 단점 (예 : 신체 활동을하는 모범 사례는 당신이 나와 같은 가능성을 줄입니다. 소파 감자)을 줄입니다.

• 프로덕션 인스턴스 또는 내부 개발 인스턴스에만 적용됩니까?

• 최소한 프로덕션 환경에서는 보안 모범 사례 (환경 요구 사항에 따라 테스트 및 수정)를 구현하는 것이 좋습니다. 그러나 개발시 프로덕션 데이터 (민감한 등)도 사용하는 경우 개발 관행을 변경해야한다는 강력한 표시입니다.

마지막 질문을 해결하기 위해 모든 개발 데이터베이스에서 SA 계정을 사용합니다 (암호는 "sa"임).

그러나 데이터를 저장하지 않고 데이터를 생성하지 않습니다. 우리의 데이터베이스는 C / C ++ 애플리케이션의 데이터 저장소에만 사용됩니다. 이러한 개발 데이터베이스에는 순수하게 테스트 데이터가 포함되어 있으며 자주 작성, 삭제, 수정 등이 발생합니다. \

또한 모든 개발 데이터베이스는 중요하게 개발 시스템에 설치됩니다. (적어도 개발자 당 하나의 사본입니다!) 따라서 누군가가 전체 설치를 엉망으로 만들면 다른 사람은 엉망이됩니다.

데이터베이스, 테이블 및 데이터가 실제로 일관되고 안전하다는 것을 보장하려는 환경에서는 훌륭한 SA 암호가 필요합니다. 약한 상태로두면 모든 사람과 모든 사람이 데이터에 대한 전체 액세스 권한을 가지며 데이터베이스를 완전히 파괴 할 수 있습니다.

순수 테스트 데이터를 포함하는 데이터베이스에 자신의 복사본을 개발자의 무리, 나는 여전히 강한 SA 계정을 유지하기위한 고체 인수를 찾을 못하고있다.

제공된 기본 SQL Server 시스템 보안 매개 변수를 수정해야합니다. 인증에 혼합 모드를 사용하지 않는 것이 좋습니다 (Windows 및 SQL Server 인증 모두 사용 가능). 대신 Windows 인증으로 전환하면 Windows 암호 정책이 적용되어 암호 길이, 수명 및 기록을 확인할 수 있습니다. SQL Server 인증과 다른 Windows 암호 정책 기능은 로그인 잠금입니다. 로그인 시도가 여러 번 실패하면 로그인이 잠기고 나중에 사용할 수 없게됩니다.

반면에 SQL Server 인증은 무차별 대입 공격 시도를 탐지하는 방법을 제공하지 않으며, 더 나쁜 점은 SQL Server가 다수의 빠른 로그인 시도를 처리하도록 최적화 된 것입니다. 따라서 SQL Server 인증이 특정 SQL Server 시스템에서 필수 인 경우 SA 로그인을 비활성화하는 것이 좋습니다.