개발자에게 SELECT프로덕션 데이터베이스 를 쿼리 ( / 읽기 전용) 할 수있는 권한을 부여해야합니까 ? 내가 근무했던 이전에는 개발 팀이 그 db_datareader역할을 담당했습니다. 내가 지금 일하는 곳에서 개발 팀은 프로덕션 인스턴스에 연결할 수도 없습니다.

테스트 인스턴스 중 하나는 일주일에 한 번 프로덕션 백업에서 복원 된 프로덕션 사본이므로 개발자가 실제로 데이터를 보는 데 아무런 문제가 없습니다.

개발자가 프로덕션을 쿼리 할 수없는 좋은 이유는 무엇입니까 (단순히 민감한 데이터를 읽을 수있는 액세스 권한을 원하지 않는 경우 제외)?

실제로 개발자에게 지원 책임이 있는지 여부에 따라 다릅니다. 이들이 세 번째 라인 지원을 원한다면 프로덕션 데이터베이스를보고이를 수행해야 할 것입니다.

일반적으로 실제로 수행 할 필요가없는 한 프로덕션 서버에서 작업을 수행하는 것은 좋지 않습니다.

대부분의 개발 목적으로 프로덕션 데이터베이스의 미러 또는 스냅 샷이 적합하며 아마도 실제 프로덕션 데이터베이스보다 좋습니다. 통합과 관련된 작업을 수행하는 경우 그 안에있는 것을 제어 할 수있는 안정적인 데이터베이스 환경이 필요합니다. 화해와 관련된 모든 것 또한 통제 된 시점을 볼 수있는 능력이 필요합니다.

문제가 프로덕션 미러 환경이 없거나 개발자를 위해 프로덕션 데이터 사본을 넣을 수있는 방법이 아니라면 다소 다른 질문입니다. 이 경우 개발자에게는 실제로 하나 이상의 미러 환경이 필요합니다. 데이터에 어떤 문제가 있는지 알 수 없으면 문제를 해결하기가 어렵습니다.

아니.

개발자 는 다음과 같은 이유로 프로덕션 데이터베이스 시스템에 액세스 할 수 없어야합니다 .

1. 가용성 및 성능 : 데이터베이스에 대한 읽기 전용 권한을 갖는 것은 무해합니다. 잘못 작성된 쿼리는 다음을 수행 할 수 있습니다.

   1. 다른 중요한 프로세스를 차단하는 테이블 잠금.
   2. 다른 프로세스가 디스크에서 데이터를 다시 읽도록하여 데이터 캐시를 폐기하십시오.
   3. 스토리지 계층에 세금을 부과하여 해당 스토리지를 공유하는 다른 서비스에 영향을줍니다.

2. 보안 : 프로덕션 데이터베이스에는 다음과 같은 민감한 정보가 포함될 수 있습니다.

   • 비밀번호 해시
   • 청구 정보
   • 기타 개인 식별 정보

   이 정보에 절대적으로 액세스해야하는 사람 만 정보를 가져야합니다. 잘 조직 된 회사에서 개발자는 그러한 사람들 사이에 있지 않습니다. 또한 개발자가이 데이터를 사용하여 프로덕션 시스템에 액세스 할 수 있으면 회사는 PCI 및 SOX 준수에 실패합니다.

   그 이유는 분명합니다. 개발자의 개발 작업은 실제로 진행되기 전에 여러 가지 과정을 거칩니다. 직접 프로덕션 액세스 권한을 가진 악의적 인 개발자가 프로덕션 데이터를 훔치거나 라이브 데이터베이스를 무릎 꿇는 것을 막을 수있는 것은 무엇입니까?

   "하지만 DBA도 마찬가지입니다! 그들은 그렇게 할 수 있습니다!" 바로 그거죠. 책임감있게 가능한 한 많은 수퍼 유저를 원합니다.

예.

개발자 는 프로덕션 시스템에 액세스 할 수 있어야 합니다.

우리 회사에는 프로덕션 데이터베이스를 다루는 4 개의 팀이 있습니다. 그들은:

1. 데이터베이스의 스키마와 코드를 디자인하고 작성하는 개발자 . 프로덕션 데이터베이스에는 액세스 할 수 없습니다. 그러나 때때로 관리자 나 지원 담당자와 함께 앉아 실제로 무언가를 볼 수 있도록 도와줍니다.
2. 프로덕션 데이터베이스를 배포, 모니터링 및 관리하는 관리자
3. 시간에 민감한 생산 문제를 조사하고 개발자에게 수정 사항을 개발할 수 있도록 피드백을 제공하는 직원을 지원하십시오 .
4. Business Intelligence 직원 은 정기적으로 새로 고쳐진 데이터베이스 사본 또는 신중하게 작성된 QA 추출 (보통 관리자가 설계)을 사용하여 프로덕션 데이터베이스에서 데이터를 추출합니다.

이러한 다른 그룹에 특정 결함이있는 경우 개발자에게 프로덕션 액세스 권한을 부여하는 것이 좋습니다.

예를 들면 다음과 같습니다.

• 지원팀이 없습니다. 시간에 민감한 생산 문제를 어디에서 디버깅해야하는지 누가 알겠습니까? 개발자 " 유리를 깨십시오 "액세스 권한을 부여하십시오.
• BI 팀이 없습니다. 관리자는 보고서 또는 추출과 관련이 없거나 원하지 않습니다. 매일 아침 execs가보고하는 보고서의 문제점을 해결하는 사람은 누구입니까? 개발자 이들 보고서 및 추출을 디버그 할 수있는 제한된 액세스 권한을 부여하십시오.
• 관리자 팀이 없습니다. 당신은 매우 작은 회사 또는 신생 회사에 있습니다. "우연한 DBA"에 인사하십시오. 개발자는 관리자의 역할을 두 배로 늘리므로 프로덕션에 대한 전체 액세스 권한이 필요합니다.

성능이 큰 이유입니다.

데이터를 변경할 수 없다고해서 서버에 영향을 줄 수 없다는 의미는 아닙니다. 잘못 작성된 쿼리는 프로덕션 환경을 무너 뜨릴 수 있으며 tempdb 오버플로와 같은 다른 문제를 일으킬 수 있습니다.

SELECT *
FROM BigTable A, OtherBigTable B
ORDER BY Somecolumn

이것이 재난의 요리법입니다. 이 명령은 order by가있는 직교 곱 제품이므로 tempDB로 정렬됩니다.

원칙은 "최소한 권한"과 "알아야 할 것"입니다. 개발자가이 테스트를 통과합니까?
특히 감사원이나 Sarbannes-Oxley가 노크 할 때.

그런 다음 다음 가정 : 개발자는 바보입니다. 그래서 그들은 누가, 3 선 지원을 위해 말을해야하는 경우 다음 그것을 필요로? 웹 원숭이는 일반적으로 데이터베이스 유형을 지원할 것으로 예상되는 경우 데이터베이스 유형을 지원합니다.

그렇다면 액세스가 영구적으로 필요합니까? SQL 로그인 또는 사인 오프가 필요한 대체 Windows 계정을 사용하여 "break glass"액세스 권한을 가질 수 있습니다. 우리의 경우, 데이터 소유자 (일부 기술에 정통한 비즈니스 전문가)와 IT 관리자가이를 승인했습니다.

나는 한 개발자에 대해 테스트 또는 생산에 쿼리를 실행하고 볼 을 아래로 가지고 있기 때문에 무지. 즉, 개발자는 자신의 행동에 책임을 져야합니다. 서버를 중단 시키면 그에 따라 문제가 발생합니다. 한 번의 사건으로 누군가 강등당했습니다.

이들은 물론 합리적인 크기의 상점을 가정합니다. 모자를 많이 쓰는 사람은 할 수있는 의무의 분리가 줄어 듭니다.

또한 개발자가 최근 데이터에 대해 쿼리를 실행할 수있는 환경이 있습니까? 마지막 상점에서 prod는 매일 밤 테스트 서버로 복원하여 제공했습니다.

나는 IT가 많은 것들과 마찬가지로 "의존적"이라고 답합니다.

민감한 회사 및 고객 정보가 많은 대규모 ERP 데이터베이스? (보안 및 성능상의 이유로) 아마 아닐 것입니다.

도넛과 피자 펀드에 대한 기여를 추적하는 Access 프론트 엔드가있는 부서별 5MB 데이터베이스? 적어도 읽기 전용 액세스의 경우 큰 차이를 만들지 않을 것입니다.

물론 첫 번째 예는 두 번째 예보다 훨씬 일반적이지만 이러한 유형의 정책 결정을 담당하는 경우 알아야 할 차이점이 있습니다. 그러나 반대로, 5MB 도넛 및 피자 펀드 데이터베이스가 50GB 부품 번호 / 고객 신용 카드 번호 / 누가 아는 것까지 얼마나 빨리 범위를 넓힐 수 있는지 놀랍습니다. 당신이 그것을 허락하면 else 데이터베이스.

일반적인 24/7 OLTP 환경에서는 일반 개발자가 프로덕션에 허용되지 않아야합니다. 기간! 요청에 따라 권한이 부여 될 수있는 것보다 특정 이유가 나타나는 경우가 있습니다. 그러나 보통은 아닙니다.

나는 이것에 대한 많은 이유를 보았다 :

• 큰 테이블에서 SELECT * :

  • 성능 문제 (카테 시안 제품);
  • 결국 사이트를 무릎으로 가져간 문제를 차단합니다.
  • 복제를 중단시키는 블로킹 체인;
  • TempDB 드라이브를 가득 채운 큰 데이터 세트를 주문합니다. 완전한 광기를 일으켰습니다 :-)!
  • 그날 밤 담당 DBA의 고혈압;

• 민감한 데이터 읽기 (개발자는 신용 카드 정보 또는 사용자 개인 정보에 액세스 할 수 없음);

더 많은 이유가 있다고 확신합니다.

• 보안 : 개발자가 정보를 사용할 수있게되면 중요한 정보가 삭제 될 수 있습니다.
• 편집증 : 일부는 선택 액세스만으로 여전히 데이터를 망칠 수 있다고 생각할 수도 있습니다.
• 성능 : 쿼리는 수행하는 데 약간의 리소스가 필요하므로 개발자가 코드를 작성할 때 완벽하다고 말할 수는 없습니다.

고려해야 할 몇 가지 항목

• 데이터가 민감합니까?
• 프로그래머가 핵심 신뢰할 수있는 팀 또는 일부 해외 팀의 구성원입니까?
• 성능에 영향을 미치는 관점에서 쿼리되는 데이터의 규모는 얼마입니까?
• 프로젝트 규모 또는 관련 비용은 얼마입니까?
• 가동 시간이 얼마나 중요합니까?

적은 비용으로 더 적은 프로세스가 필요하며 더 빠른 개발 흐름이 필요합니다.

달러 가 클수록 더 많은 프로세스 요구 사항이 더 엄격한 표준 개발 관행을 필요로합니다.

당신이하고있는 것에 당신의 관습을 적응 시키십시오.

저는 대기업의 개발자로 일하고 있습니다. 모든 종류의 지원 (기본적으로 모든 지원)을 수행 할 모든 개발자는 관련 프로덕션 데이터베이스에 액세스 할 수 있습니다. 특정 팀만 말할 수 는 있지만 액세스 권한 이있는 이유를 알려 드리겠습니다 .

1. 우리는 일상적인 처리를 주시하기 위해 실시간 액세스가 필요합니다. (대시 보드가있는 동안 사물에 대해 심도있게 살펴볼 수 있어야합니다. 대시 보드에서이 기능을 사용하는 것이 좋지만 실용적이지 않은 것으로 나타났습니다.)
2. 지연이 큰 영향을 미칠 수 있으므로 생산 실패를 조사하려면 실시간 액세스가 필요합니다. (나는 여기서 우리의 실패에 대해 이야기하지 않을 것이다. 그들은 온갖 종류로 온다)
3. 우리는 종종 비즈니스 사용자를 위해 사용자 정의 보고서를 작성해야하며이 정보는 최신 상태 여야합니다. (dba는 이것을 할 시간이 없으며 우리는 그것들을 기다릴 시간이 없습니다. 물론 비 이상적입니다.)
4. 프로덕션 DDL / DML 배포 / 패치의 검증을 수행해야합니다. (DBA는 배포하지만, 구조화 방법 만 알고 있습니다. DBA보다 데이터베이스 구조에 대해 더 많이 알고 있습니다. 여기서는 이상 할 수 있지만 비즈니스가 매우 복잡하기 때문에 데이터베이스가 매우 복잡합니다.)

성능이 중요합니다. 우리는 속도 저하를 일으키는 개발자가 있습니다. 그러나 이러한 인스턴스는 격리 된 인스턴스이며 SQL의 성능이 너무 높아 개발자가 쿼리의 영향을 이해하지 못하는 경우가 거의 없습니다.

이 질문을 받으려면 현재 액세스 권한이없는 것으로 가정해야합니다. 조직에서 소프트웨어를 개발 중이고 고객 문제를 해결하기위한 것이며 고객이 데이터베이스 사본을 제공하는 경우 '예'입니다. 그렇지 않으면 개발자를 프로덕션에서 제외시키고 연구 요구에 따라 대체 환경을 만들도록 옹호합니다. 치약이 튜브에서 나오면 다시 넣기가 어렵습니다.

나는 정당화의 부담이 접근을 요구하는 사람들에게 달려 있음에 동의한다. 일반적으로 상담 한 환경에서는 소규모 환경 인 프로덕션 시스템에 액세스 할 수 있었고 지원 담당자였습니다. 지원이 지원되는 백업 등에 액세스 할 수 있었고, (전용 지원 개발자를 통한) 프로덕션 데이터에 대한 간접 액세스가있었습니다.

가장 중요한 것은 : 모든 것이 원활하게 실행되도록하기 위해이 액세스 권한이 필요하며 작동하지 않는 것에 대한 재무 담당자의 질문에 대답해야합니다. 이 경우 항상 오래된 데이터를 사용하여 작업 할 수는 없습니다. 반면에 액세스가 많을수록 더 나빠집니다. 일반적으로 컨설턴트는 필요하지 않은 한 이런 종류의 액세스를 피하는 경향이 있습니다. 재무 데이터베이스에서 작업하고 있으므로 마지막으로 원하는 송장을 입력했다는 비난을받습니다. :-D.

반면에 액세스가 필요하지 않은 경우 액세스 권한이 없어야합니다. 개발자가 아마도 올바르게 처리했는지 확인해야하기 때문에 민감한 데이터 인수를 실제로 사지 않습니다 (버그 보고서가 올 때 실제로 저장된 내용을 보지 않고 확인하기는 매우 어렵습니다). 개발자가 개발자의 앱이 저장하는 데이터를 보도록 믿을 수 없다면 개발자를 고용하여 앱을 작성해서는 안됩니다. 개발자가 데이터를 난독 처리하여 전자 메일로 보낼 수있는 방법이 너무 많습니다. 확신 할 수 없습니다. MAC 컨트롤은 여기서 도움이되지만 여전히 구현하기가 상당히 복잡합니다.

내 입장에서 가장 큰 문제는 쓰기 액세스와 관련이 있습니다. 개발자가 액세스 권한이없는 경우 개발자는 쓰기 권한이 없습니다. 책의 무결성을 확인하려면 가능한 한 적은 수의 사람에게만 쓰기 권한을 유지하려고합니다. 개발자가 액세스 할 수없는 경우 감사 내역을 훨씬 쉽게 검증 할 수 있습니다. 개발자가 읽기 액세스 권한을 가지고 있다면 쓰기 액세스 권한을 부여 할 수있는 권한 부여 첨부가 있는지에 대한 질문이 항상 있습니다 (저장 프로 시저 SQL 삽입 일 수 있습니다). 스테이징 환경에 액세스 할 때 종종 클라이언트 청구 정보에 대한 전체 액세스 권한이있었습니다. 그래도 작동하는 준비 환경이있는 경우 필요하지 않은 경우 프로덕션에 액세스 하지 않도록 적극적으로 요청 합니다.

물론 이것은 완벽하지 않습니다. 개발자는 여전히 쉽게 감지 할 수없는 애플리케이션에 백도어를 구축 할 수 있지만 백업 데이터를 하루 전에 사용할 수 있다는 사실을 고려할 때이 접근 방식은 합리적인 접근 방식입니다.

도움이 되었기를 바랍니다.

편집 : 내가 작업 한 더 큰 환경에서 금융 시스템의 경우 며칠에서 몇 개월까지 전체 백업 데이터에 액세스 할 수있었습니다. 이것은 항상 내 작업에 충분했으며 재무 담당자가 새로운 데이터로 테스트하여 생산과 비교할 수있는 능력이 필요할 때뿐이었습니다.

액세스 권한이없는 것은 개발자와 다른 사람들이 실수로 데이터를 손상 시키거나 보지 않도록 보호하는 좋은 방법입니다. 또한 회사가 법을 위반하지 않도록 보호합니다 (예 : Hipaa 위반 및 개인 정보 보호 문제)

개발자는 실제로 프로덕션 환경에 액세스 할 필요가 없으며 거친 버그를 재현 할 수없는 경우 개발자의 관점에서 보면 더 쉽습니다.

그러나 개발자는 미니 덤프 또는 로그 파일을 넣고 PDB 심볼 파일을 사용하여 버그를 다시 만들 수 있습니다.

데이터를 테스트 환경으로 가져와야하는 경우 어떤 종류의 프로세스에서 추가 작업을 생성 할 수있는 데이터를 스크러빙하는 것이 일반적입니다.

프로덕션 호출에 사용되는 데이터베이스 소프트웨어에 따라 개발자가 데이터베이스에 액세스하려면 새로운 라이센스가 필요할 수 있으며, 이는 단순히 읽기 액세스 권한을 갖는 데 많은 비용이 듭니다.

회사에서 프로덕션 문제를 디버깅하거나 연구 할 수있는 도구를 제공하지 않는 경우 프로덕션 데이터에 액세스 할 수 없기 때문이 아닙니다.

데이터는 대부분의 응용 프로그램에서 가장 중요한 부분입니다!

성능이 이유 중 하나 일 수 있습니다.

개발자 쿼리는 종종 비효율적 일 수 있으며, 제대로 조정될 때까지 과도한 잠금 또는 리소스 사용을 유발합니다.

프로덕션 시스템은 개발자가 실험하기에 적합한 장소가 아닙니다.

그것은 DBA와 개발자에 대한 자신감에 달려 있습니다. 일반적으로 개발자에게는 프로덕션 데이터베이스에 대한 쿼리 (읽기) 권한이 부여됩니다. 경험상 개발자 는 테스트 / 개발 데이터베이스로만 작업 해야 합니다.

문제는 대부분의 소프트웨어 응용 프로그램이 데이터 중심이라는 점입니다. 따라서 응용 프로그램에서 문제를 해결하려고 할 때 실제로 문제를 일으키는 데이터를 확인해야합니다. 따라서 개발자는 실제로 어떤 형태의 액세스가 필요합니다.

SQL 로그인을 사용하여 테이블에 대한 읽기 전용 액세스 권한 만 부여하는 것이 좋습니다. 그러나 20 조인으로 쿼리를 만들거나 수백만 개의 레코드가있는 테이블에서 SELECT *를 수행하지 못하게하는 이유는 무엇입니까? 이러한 쿼리는 실수로 데이터베이스 및 스토리지의 성능을 저하시킬 수 있습니다.

우리 회사 Stackify는 이것을 해결하는 영리한 방법을 고안했습니다. 개발자는 소프트웨어를 통해 쿼리를 실행할 수 있으며 쿼리 계획을 사용하여 쿼리가 SELECT 문이고 쿼리의 예상 비용이 낮고 몇 개의 레코드 만 반환하는지 확인합니다. 이런 식으로 그들은 많은 해를 끼칠 수 없습니다. 또한 실행되는 모든 쿼리를 감사합니다.

이것은 우리가 제공하는 것 중 하나 일뿐입니다. 에서 우리를 확인 http://www.Stackify.com 우리에 대해 자세히 배울 개발 운영 지원 솔루션을.

예. 경우에 따라 개발자를 포함하여 일부 사용자 하위 집합에 쿼리 프로덕션 데이터에 대한 일정 수준의 액세스 권한을 허용하는 것이 합리적입니다. 그러나 두 가지 이유로 적절한 제한이 있어야합니다. 먼저, DBA로서 모든 사용자에게 필요한 서비스 수준을 보장하기 위해 최선을 다해야합니다. 또한 대량 삭제 또는 비즈니스 규칙 위반과 같은 의도하지 않은 잘못된 쿼리를 방지하려고합니다. 적절한 보안 통제가 이루어져야한다는 것은 말할 필요도 없습니다.

데이터베이스 테이블에 대한 임시 쿼리를 직접 허용하지 않은 이유가 무엇이든 쿼리에 뷰 및 저장 프로 시저를 허용하는 경우가있을 수 있습니다. 데이터베이스 권한을 사용하면 SELECT 쿼리가 테이블을 직접 쿼리하지 못하게하고 특정 사용자가 액세스 할 수있는 뷰 및 저장 프로 시저를 제한 할 수도 있습니다. 이 방법은 사용자 기반에 유연성을 제공 할뿐만 아니라 올바르게 구현 될 때 데이터 무결성과 현실성을 보호합니다.

우리 회사에서는 프로덕션 서비스에 의존하지 않는 프로덕션 데이터베이스의 읽기 전용 슬레이브를 유지 관리합니다. 우리는 개발자에게 프로덕션 데이터에 액세스 할 수있는 권한을 개발자에게 부여합니다. 민감한 데이터 (고객 정보, 지불 정보 등)가있는 경우 해당 테이블의 복제를 제한하고 슬레이브 서버에서 샘플 데이터 테이블을 유지합니다.

아뇨.

이것이 개발 / 테스트 / UAT 서버가있는 이유입니다. 프로덕션의 데이터는 테스트 환경으로 복사 될 수 있으며 개발자는 테스트를 진행할 수 있습니다. 프로덕션 환경에서는 선택 쿼리가 매우 해로울 수 있습니다. 로드가 증가하고 피크 시간에 전체 성능이 저하 될 수 있습니다.

필요한 정보는 원하는 것을 실행 (선택)하고 결과를 보낼 수있는 DBA를 통해 이동해야합니다. 그것이 우리가 환경에서하는 방식입니다.

왜 모든 사람이 개발자가 바보이고 아무것도 모른다고 생각하는지 잘 모르겠습니다. 나는 그들이 엉망이고 "생산"해서는 안되는 수많은 다른 역할의 샘플을 얻습니다. DBA, Sys Admins, Network Admins, Developers 등이 모두 엉망입니다.

정상적인 네트워크 로그인이있는 환경의 어느 서버 (dev, dba, sa)도 어떤 서버 나 데이터베이스에도 액세스 할 수 없습니다. 모두 사용해야하는 특정 "관리자"계정이 있습니다. 예, 일반적으로 dba와 sa는 더 자주 사용하지만 가볍게 밟아야합니다. 나는 모두에게 화상을 입었다.

따라서 좋은 날에는 IT 역할에 액세스 할 필요가 없습니다. 그러나, sh! t는 팬을 때리고, 갑판에 손을 얹고 문제를 해결하는 적절한 사람들이 필요합니다. 이것은 일반적으로 응용 프로그램을 알고 dba 및 sa를 특정 지점으로 안내하는 개발자가 이끈다. 불필요한 지연 또는 요청 및 승인일뿐입니다.

또한 승인 후에는 어떤 유형의 감사도 수행되지 않으므로 승인은 아무 의미가 없습니다.