애플리케이션이 sa 계정을 사용하지 않아야하는 이유

나의 첫번째 질문은, 부드럽게 해주세요. sa 계정을 사용하면 SQL Server 및 모든 데이터베이스, 사용자, 권한 등을 완벽하게 제어 할 수 있습니다.

나는 응용 프로그램이 완벽하고 비즈니스에 중점을 둔 이유없이 sa 암호를 사용해서는 안된다는 절대적인 믿음을 가지고 있습니다. 이 질문에 대한 답변 에는 IT 중심 토론에 대한 많은 추론 이 포함됩니다

sa 암호를 사용하지 않으면 작동하지 않는 새로운 서비스 관리 시스템을 수락해야합니다. 평가를 설정할 때 이유를 해결할 시간이 없었지만 서버 팀은 db_creater 및 필요한 다른 권한을 통합하여 설정 한 고정 된 역할을 사용하도록 설치하려고했습니다. 실패했습니다. 그런 다음 서버 팀이 sa 계정으로 설치하도록했지만 데이터베이스에 대한 dbo 역할의 계정으로 실행되었지만 실패했습니다. 심하게 나는 sysadmin 역할의 계정으로 실행하려고했지만 실패했지만 유용한 오류 메시지가 없어서 가능한 시간보다 더 많은 시간을 소비하지 않고 진행중인 작업을 해결할 수있었습니다. 구성 파일에 일반 텍스트로 저장된 sa 계정 및 비밀번호로만 작동합니다.

이 질문을하고 서버 팀이 공급 업체와 이야기했을 때 그들은 '무슨 문제가 있습니까?'라는 걱정스러운 대답을 얻었습니다. 그런 다음 '암호 스크램블링을 볼 수 있습니다'스크램블링 ffs

파일에 대한 액세스를 제한하는 방법과 수단이 있지만 내 의견으로는 보안의 또 다른 약점이라는 것을 알고 있습니다.

어쨌든, 내 질문은, 누군가가 왜 이것이 나쁜 일이고 왜 큰 no no가되어야하는지 이유를 비즈니스에 설명하는 데 사용할 수있는 문서를 알려 줄 수 있습니까? 나는 보안을 진지하게 받아들이고 비즈니스를 이해하고 궁극적으로 순위가 떨어질 수 있지만 어려움을 겪고 있음을 의미하는 분야에서 일합니다.

그것은 귀하의 비즈니스에 따라 다르지만 대부분의 경우에 중요한 것은 확인이되어 있는지 확인하는 것입니다 하지 의 IT 문제로 본. 그것은 보안 문제이며, 두 개의 중복되는 비즈니스 peopel은 "일반 IT에 대한 신음"보다는 "보안"이라고 말하면들을 가능성이 더 큽니다.

보안 요구 사항이있는 클라이언트와 작업합니까? 시작하기에 좋은 곳입니다. Sa 수준의 액세스 권한을 가진 앱을 실행했거나 권한있는 액세스를 사용하지 않더라도 자격 증명을 올바르게 보호하지 않은 앱만 실행 한 경우 (가능한 경우 저장된 사용자 / 패스보다는 Windows 통합을 강력하게 선호 함) 보안이 적용되는 경우 감사, 감사가 실패하고 고객을 잃고 / 또는 우리 그룹의 고객에 대해 돈을 돌려 주어야 할 위험이 있습니다 (주로 내가 일하는 제품의 경우 은행 조직, 그룹의 다른 부분은 경찰과 건강을 다루고 있습니다) 당국 등) 보안은 목적에 맞는 제품의 일부입니다. 비즈니스 사람들 은 일반적으로 IT 권장 사항에 립 서비스를 지불하지 않더라도 잠재적 인 위협의 심각성을 이해합니다.

클라이언트가 부과 한 요구 사항을 무시하더라도 다양한 산업 표준 보안 표준을 충족하려고 노력하는 경우 이러한 종류의 응용 프로그램 인증은 일반적으로 간주되는 모범 사례와는 거리가 멀기 때문에 감사에 실패하게됩니다. "단순해서는 안된다"목록에 있습니다. 보안이 응용 프로그램의 중요한 부분임을 비즈니스 결정 론자에게 분명히하고,이 공급 업체가 인식하지 못하거나 (적어도 적절하게 염려하지 않는) 사실로 인해 그들이 할 수없는 것이 무엇인지 의심하게 만듭니다. 다루기 : DB 보안 모범 사례에 대해 아는 것은 그들의 일의 일부이며, 그것을 구현하는 것이 어렵지 않습니다.

또한 귀하 (구매자)는 다른 방법이 아니라 공급 업체에게 합리적인 보안 요구 사항을 지시해야한다고 지적합니다 . 귀하의 데이터이므로 충분한 것으로 간주되는 것을 진술 할 자격이 없습니다.

애플리케이션에 SA 액세스 권한이 없어도됩니다. (단순한 목적이 데이터베이스 관리인 경우가 아니라면)

비즈니스에 로그인에 필요한 것보다 많은 로그인 (응용 프로그램 또는 개인)에 더 많은 권한을 부여하지 않는 것이 일반적 규칙입니다.

완전히 안전한 응용 프로그램이 없습니다. 대부분 일종의 SQL 인젝션 또는 XSS 취약점이 있습니다. 침입자가 자신의 선택에 대한 진술을 실행하고 'SA'액세스 권한을 가진 경우, 데이터에 발생하여 비즈니스를 즉시 중단시킬 수있는 많은 일이 있습니다. (특히 법 집행 기관에서 데이터를 사용하여 데이터를 신뢰해야하는 경우) 이해 관계자에게 단일 레코드로도 의도적으로 변경을 수행 할 수 있고 정보가 유출 된 경우 수행 할 작업을 문의하십시오.

이제 'SA'액세스를 통해 응용 프로그램의 데이터베이스뿐만 아니라 시스템의 다른 모든 데이터베이스도 변경할 수 있습니다. 따라서 모든 데이터베이스의 사본을 만들어 신문에 보내면 이해 관계자에게 무엇을할지 물어보십시오. 불만을 품은 직원이이 보안 허점이 존재한다고 판단하면 이런 일이 발생할 수 있기 때문입니다.

벤더는 암호를 해독 할 수 있다고 말했다. 바로 BS입니다. 응용 프로그램은 암호를 사용하기 위해 일반 텍스트로 암호에 액세스해야하므로 암호를 해독하는 키가 바로 옆에 해독되지 않은 상태로 저장됩니다. 또한 앞에서 언급했듯이 실제 문제는 누군가이 암호를 찾는 것이 아닙니다. 취약점을 통해이 시스템을 사용하는 사람들 (mis)은 암호를 보지 않고도 모든 데이터베이스에 완전히 액세스 할 수 있습니다.

SA가 필요한 가장 큰 원인은 응용 프로그램이 SQL 에이전트와 상호 작용해야하기 때문입니다. 적어도 그것은 제대로 구현하기가 더 어려운 기능 중 하나이며 대부분의 사람들은 "SA 사용"경로를 사용하여 문제를 해결합니다. 'SA'자체가 필요한 것은 공급 업체가 sysadmin 권한을 확인하는 방법을 모르기 때문일 수 있습니다.

시도 할 수있는 두 가지 솔루션이 있습니다.

1. SA (보안 모범 사례)의 이름을 바꾸고 제한된 권한으로 'SA'라는 새 계정을 만듭니다. (이것을 시도하지 않았지만 작동해야 함)

2. 소프트웨어를 설치하지 마십시오. 전문가로서 귀하는 해당 조치에 대한 책임을지지 않으므로 설치할 수 없습니다. 비교를 위해 배관공에게 가스통을 벽난로 대신 직접 가스통로를 통과시켜 파이프 / 돈을 절약하도록 요청하십시오. 이 이미지를보고 웃을 수도 있지만 적절한 비교라고 생각합니다.이 소프트웨어는 조만간 폭발 할 것입니다. 그리고 그렇게되면 사업도 중단 될 수 있습니다.

이 모든 것이 "그들"이이 소프트웨어를 필요로하지 않는 경우, 내가 줄 수있는 마지막 권장 사항은 실행하는 것입니다. 데이터에 문제가 발생하면 가장 먼저 책임을 져야합니다. 따라서이 응용 프로그램을 사용하면 아마도 직업 보안이 없을 것이므로 적어도 일부를 제공하는 고용주를 찾으십시오.

나는 이것을 공격하는 두 줄을 봅니다.

• 준수 . 상점에 적용되는 규정 준수 기준이 있습니까? 해당 문구를주의 깊게 검색하여 응용 프로그램 '요구 사항'과 호환되지 않는 항목이 있는지 확인하십시오. sa응용 프로그램 에서 사용 하지 못하는 것을 발견 하면 응용 프로그램이 비즈니스 등을 책임지게 할 수 있으므로 방탄 수밀 케이스가 있습니다.

• 사용자 관리자 액세스 . sa액세스 가 필요한 응용 프로그램이 실제로 sa응용 프로그램이 설치된 워크 스테이션에 대한 관리자 권한이있는 모든 회사 사용자 에게 액세스 권한을 부여 하는 경우를 분명히 제시해야합니다 . 숨기기 방법이 없습니다 sa응용 프로그램이 실행되는, 즉 A는 지역 관리자 암호가 사실 이를 방지 할 수 있습니다 '스크램블링'없이 양. 원하는 경우 로컬 관리자가 얻을 수없는 로컬 신뢰 루트는 없습니다. 필요한 응용 프로그램이 있으면 응용 프로그램을 실행하는 모든 사용자 sa에게 sa권한을 부여하는 것과 같습니다 . 그 의미, 사용자가 효과적으로 할 수있는 것을 설명하십시오.

  • 읽을 수 있는 이 응용 프로그램에서하지만 다른 데이터베이스에서뿐만 아니라, 서버에서 데이터를 해당 서버에서 호스팅
  • 동일한 서버의 다른 데이터베이스에서 서버의 데이터를 다시 수정 하는 기능
  • 수정 후 그의 행동 흔적을 지우는 기능
  • 특정 조치가 다른 사용자에 의해 수행 된 것으로 보이도록 감사 및 히스토리를 변경하는 기능
  • SQL Server 자격 증명을 사용 하여이 서버를 신뢰 하는 다른 리소스 에 대한 공격을 에스컬레이션 할 수 있습니다. 이는 SQL Server를 디딤돌로 사용할 수 있으므로 파일 공유, Exchange 서버 등을 포함하지만 이에 국한되지 않는 다른 모든 SQL Server뿐만 아니라 다른 리소스도 포함 할 수 있습니다.

의사 결정자에게이 응용 프로그램을 승인하면 관리자가있는 모든 직원 에게 응용 프로그램 을 실행하는 워크 스테이션에 대한 액세스 권한을 위에서 언급 한 모든 특권으로 위임해야 함을 분명히하십시오 . 공급 업체는 sa응용 프로그램 의 암호를 일종의 '암호화'또는 다른 방식으로 호출하여 자체 방어를 시도 합니다. 이것은 물을 보유하지 않습니다. 관리자의 공격을 견딜 수있는 암호화 체계는 없습니다. 그리고 로컬에서 '숨겨진'암호를 찾는 데 필요한 기술 기술의 양이 완전히 관련이 없음을 분명히하십시오. 직원들은 스스로 그것을하지 않을 것입니다. 그들 중 하나는 구글을 위해 그것을 사용하고 그것을하는 사용하기 쉬운 스크립트를 발견 할 것입니다.

먼저, sa 암호는 일반 텍스트를 저장 했습니까? 지갑으로 투표해야합니다. 그것이 용납 될 수 있다고 생각하는 사람은 사업을 중단해야합니다.

다음은 문제를 설명하는 데 도움이 될 수있는 신학입니다. Alice 직원은 1 층에 액세스해야합니다. 건물 전체에 마스터 열쇠를 주거나 1 층 열쇠를 주나요? 답 : 1 층 열쇠 만 주면됩니다. 왜? 우발적 또는 고의적 손상 가능성을 줄이므로 앨리스가 처음부터 2 층 서버 룸에 갈 수 없다면 그곳에서 나쁜 일을하지 않을 것입니다.

최소 권한의 원칙입니다.

응용 프로그램에서 sa 계정을 사용해야하는 이유는 PerfMon 또는 확장 이벤트가 대답 할 수있는 질문입니다. 응용 프로그램 이름으로 필터링 된 T-SQL 템플릿을 사용하여 PerfMon 추적을 만듭니다.

내 머리 위로 sa를 사용하는 것에 대한 또 다른 논쟁이 있습니다. sa 계정을 사용하려면 SQL Server 서비스가 혼합 인증 모드에 있어야합니다. Kerberos의 모든 보안 기능을 활용할 수있는 경우에만 Windows 인증 만 사용하는 것이 좋습니다.

기술적 인 관점에서 볼 때 응용 프로그램에 SA 권한이 필요한 이유는 없습니다. 아마도 응용 프로그램 개발자가 로그인에 sysadmin 권한이 있는지 확인하고 그렇지 않은 경우 단순히 오류 메시지가 표시 될 수 있습니다. 이렇게하면 응용 프로그램에 SA 권한이 필요하다고 주장 할 수 있습니다.

이 응용 프로그램이 있어야하는 경우 다른 응용 프로그램이없는 별도의 인스턴스에서 실행합니다.

아마도 공급 업체가 응용 프로그램의 어딘가에 XP_CMDSHELL을 사용하고 있기 때문에 "sa"를 요청 / 필요할 것입니다. (XP_CMDSHELL에 대한 무제한 액세스로 가능한 손상을 시작하지 마십시오. 데이터뿐만 아니라 호스트 컴퓨터 및 네트워크상의 다른 관리자 액세스 권한도 잠재적으로 열릴 수 있습니다.)

합법적 인 요구가있는 경우 프록시 계정을 통해 액세스를 제한 할 수 있습니다. 예를 들어 BOL을 참조하십시오. http://msdn.microsoft.com/en-us/library/ms175046.aspx

어떤 응용 프로그램도 SA 계정과 암호를 요구하지 않아야합니다.

그러나 IT 서비스 관리 제품을 설치했으며 설치 과정에서 설치 프로그램이 DB를 작성하고 소프트웨어에서 사용할 계정을 DB에 연결할 수 있도록 SA 계정 신임 정보를 제공 할 수 있습니다. SA 계정 자격 증명은 응용 프로그램 또는 설치 관리자 로그에 어디에도 저장되지 않습니다. 이 소프트웨어는 설치 중에 미리 작성된 데이터베이스를 사용하는 옵션도 제공합니다.

따라서이 IT 서비스 관리 소프트웨어의 설치 또는 운영에 SA 계정이 필요한지 확인합니다.

설치하는 경우 : 임시 'sa'계정을 작성하고 설치를 수행 한 후 계정을 제거하십시오.

작동하는 경우 : 전염병과 같은 소프트웨어를 사용하지 마십시오. (또는 하나의 데이터베이스 만 보관할 독립형 SQL 서버를 설정하십시오.)

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

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