SA 계정 및 기타 알려진 계정 이름은 어떤 보안 위협에 해당합니까?

sa와 같은 알려진 계정 이름이 데이터베이스에 보안 위협이 있습니까? SQL Server에서 Windows 인증을 사용할 때 동일한 암호 정책을 적용합니까 (5 번 후에 계정 잠금이라고 설정 한 경우)?

sa와 같은 알려진 계정 이름이 데이터베이스에 보안 위협이 있습니까?

알려진 이름을 가진 "신"사용자 계정은 일반적으로 덜 알려진 이름을 가진 신 사용자보다 나쁜 생각으로 간주됩니다. 공격자가 사용자 이름 과 암호가 아닌 암호 만 추측하면되기 때문에 무차별 대입 공격이 훨씬 쉬워집니다 .

어쨌든 신 사용자를 갖는 것은 위험 할 수 있습니다. 일반적으로 특정 사용자에게 필요한 작업에 대한 특정 권한을 갖는 것이 좋습니다. 이러한 종류의 권한 기반 보안은 나중에 환경에 추가하는 것보다 처음부터 쉽게 구현할 수 있습니다.

sa를 비활성화하고 특정 사용자에게 SQL 서버에 필요한 특정 관리자 권한을 root부여하는 것은 sudoLinux 및 이와 유사한 기능을 통해 필요한대로 관리자 권한을 비활성화 및 배포 하는 것과 동일한 권장 사항 입니다. 문제가 발생할 경우 sa적절한 권한으로 머신에 직접 연결된 후에 는 항상 다시 활성화 할 수 있으며 Linux에 대한 루트 액세스를 엔지니어링 할 때와 마찬가지로 사용자가 작동하고 문제를 해결하는 데 필요한 모든 권한을 포기하게됩니다 상자에 물리적으로 액세스 할 수있는 경우 상자-계정을 비활성화하면 마법의 총알이 아닙니다. 그러나 공격자가 컴퓨터에 물리적으로 액세스하거나 RDC 또는 SSH를 통한 전체 관리 액세스 권한을 가지면 모든 베팅은 종료됩니다.

SQL Server에서 Windows 인증을 사용할 때 동일한 암호 정책을 적용합니까 (5 번 후에 계정 잠금이라고 설정 한 경우)?

Windows 통합 인증을 사용하는 경우 SQL Server는 계정 잠금을 제어 할 수 없으며 Windows 사용자를 SQL 사용자에게 매핑하고 OS가 사용자에게 적절한 자격 증명을 제공했음을 보증하도록 요청합니다. 대화 형 휴먼 사용자의 경우 이는 사용자가 SQL Server에 로그인하지 않고 Windows 인증을 시도 할 때 잠금이 발생 함을 의미합니다.

기본 관리자 (admin / root / postgres / sa / etc)가 실제로 시스템에 존재하지 않도록하는 것은 좋지 않습니다. 언제든지 다른 이름으로 권한있는 계정을 만들 수 있습니다.

다른 것이 없다면, 시스템을 악용하려는 사람들은 맹인으로 일하는 것처럼 쉬운 시간을 가지지 못합니다 (예 : 대화 형 쉘이 없거나 SQL 명령으로 직접 출력을 볼 수없는 SQL 주입)

계정 잠금과 관련하여 사용자가 직접 로그인하지 않는 한 누군가가 컴퓨터에 로그인 할 수있을 정도로 충분히 멀어지면 이미 전투에서 패배했습니다. 개인적으로, 나는 누군가의 사용자 이름을 얻을 수 있다면 누군가가 서비스 거부를 만들 수 있기 때문에 대부분의 경우 잠금을 선호하지 않습니다. (그리고 수퍼 유저를 잠그는가? 재미 없음).

CIS 벤치 마크를 살펴 보는 것이 좋습니다. 모든 데이터베이스에 대해 CIS 벤치 마크 가 없지만 Oracle, MS SQL, DB2 및 MySQL에 대한 권장 사항이 있습니다. 다른 것을 실행하고 있다면 권장하는 일반적인 종류를 살펴볼 가치가 있습니다.

다른 사람이 이것을 언급하지 않았으므로 추가하겠습니다. SQL Server 2005+를 사용하면 서버가 도메인의 일부이고 도메인에 비밀번호 정책이있는 경우 SQL 로그인에 비밀번호 정책을 적용 할 수 있습니다. 여기에는 암호 복잡성 요구 사항과 로그인시 암호를 강제로 변경하는 기능이 포함됩니다.

이로 인해 SQL 2005+에서 작동하고 안전하지 않은 암호로 SQL 로그인을 작성하도록 업데이트되지 않은 일부 소프트웨어 설치 프로그램에 문제가 발생할 수 있습니다.

SQL Server에는 Windows 인증과 혼합 모드의 두 가지 인증 모드가 있습니다 (Windows 인증과 SQL Server 인증 모두 가능).

첫 번째 모드는 한정된 횟수의 공격 시도 후 공격자가 로그인 잠금 (계정 잠금 정책 기능)에 노출 될 수 있으므로 무차별 대입 공격에 덜 취약합니다. 모든 인증 환경은 Windows 인증 모드를 사용하는 경우 무차별 대입 공격이 불가능하므로 잠금 정책 기능을 사용해야합니다.

SQL Server 인증 무차별 대입 공격 취약점의 경우 상황이 그리 좋지 않습니다. SQL Server 인증에는 시스템이 무차별 대입 공격을 감지 할 수있는 기능이 없습니다. 또한 SQL Server는 SQL Server 인증 자격 증명의 유효성을 검사 할 때 매우 반응이 좋습니다. 전체적인 성능 저하없이 이러한 공격을 나타내는 반복적이고 공격적인 무차별 로그인 시도를 쉽게 처리 할 수 ​​있습니다. 이는 SQL Server 인증이 무차별 대입 공격을 통한 암호 해독을위한 완벽한 대상임을 의미합니다.

또한 새로 도입 된 암호화 및 암호 복잡성 방법으로 무차별 강제 방법이 발전하고 있습니다. 예를 들어, 레인보우 테이블 (모든 가능한 문자 조합에 대한 암호화 해시 값을 역전시키기 위해 미리 계산 된 테이블)을 사용하는 공격자는 해시 된 암호를 쉽고 빠르게 해독 할 수 있습니다.

무차별 대입 공격으로부터 SQL Server를 보호하려면 다음을 고려해야합니다.

• SQL Server 인증 모드를 사용하지 마십시오. 공격자가 Windows 인증을 통해 로그인 잠금을 누르도록합니다.
• SQL Server 인증 모드를 사용해야하는 경우 공격자가 사용자 이름과 암호를 모두 추측하고 연결해야하는 SA 로그인을 비활성화하거나 제거하십시오.

sa 계정은 활성화 된 경우 SQL Server에서 모든 작업을 수행 할 수 있습니다. 침입자가이 계정에 침입하면 원하는 SQL Server 인스턴스 (및 호스트 OS)에서 무엇이든 할 수 있습니다.

SA (및 기타 잘 알려진 계정 이름)는 해커가 공격 할 수있는 잘 알려진 지점입니다. 일부 Oracle 암호는 제대로 문서화되지 않았으므로 기본 비밀번호가 항상 변경되지 않았습니다. SQL Server에서 SA 계정을 제어 한 후에는 실행중인 서버를 제어하고 원하는 코드를 실행하거나 설치할 수 있습니다. 카우보이 시절에는 SQL Server를 호스팅하는 웹 서버에 ActiveX 컨트롤을 설치하는 것이 허용되지 않습니다 (필자는 서류 작성이 필요하지 않음) .xp_cmdshell을 사용하여 컨트롤을 복사하고 설치했습니다. .