개발자는 얼마나 많은 데이터베이스 액세스 권한을 가져야합니까? [닫은]

그래서 저는 다양한 직장에서 개발자로 일했고 데이터베이스에 대한 액세스 수준이 다양했습니다. 일반적으로 프로덕션 DB 액세스 권한이 없습니다.

대부분 테스트 데이터베이스에 액세스 할 수 있지만 다릅니다. 때로는 데이터베이스와 데이터를 원하는대로 수행하고 변경할 수 있지만 일반적으로 다른 방법이 있습니다. 나는 데이터에 대한 읽기 권한 만 가질 수 있습니다.

DBA 팀이 데이터베이스를 관리하는 한 곳에서 일했는데, "검사"하기 위해 sql 스크립트로 양식을 제출하지 않으면 전혀 변경할 수 없었습니다. 그들은 일반적으로 프로젝트 자체와 많은 관련이 없었으므로 대부분 F5를 누르는 것이 었습니다.

솔직히 말해서 prod를 잠 가야하는 이유를 이해할 수 있지만 개발 및 테스트 환경에서 많은 데이터베이스 액세스 권한을 선호합니다. 나는 대부분의 개발자들이 데이터베이스를 둘러싼 합리적인 방법을 알 수 있다고 생각합니다. 하지만 의견을 듣고 싶습니다. 개발자는 얼마나 많은 데이터베이스 액세스 권한을 가져야합니까? 우리는 거기서 아무것도 깨지 않을 것을 믿을 수 있습니까?

개발자는 prod를 포함한 모든 데이터베이스에 대한 읽기 액세스 권한이 필요합니다. 때때로 문제는 Prod의 데이터가 예상했던 것과 다르며 개발자가 데이터를 재생할 수 없기 때문에 문제를 일으키는 데이터를 볼 필요가 있다는 것입니다.

개발자는 프로덕션 데이터 쓰기 권한이나 개체 생성 권한이 없어야합니다. 공식 릴리스의 일부가 아닌 제품은 없습니다. 너무 많은 시간 동안 사람들은 작동하지 않는 prod에 대한 빠른 수정을 수행하여 prod가 더 뭉개지거나 작동하게하지만 코드를 dev / QA / Staging 서버에 넣고 소스에 더 나쁜 코드를 넣는 것을 잊습니다. 제어 저장소와 코드는 다음 공식 릴리스에서 약 한 달 후에 덮어 씁니다.

다른 서버에 배포하면 배포 프로세스에 차이가 있는지 확인하는 데 도움이되므로 개발자는 전체 데이터베이스 QA 권한을 갖는 것을 선호합니다. 소스 구조의 스크립트가 아닌 GUI를 사용하여 데이터베이스 구조 변경이 발생하는 방식).

자체 서버 세트를 보유 할 새로운 엔터프라이즈 유형 클라이언트가있는 경우, 사용하기 전에 권한이 완화 될 수 있습니다. 이것은 많은 일이 일어나야하고 제품을 생산할 수있는 소수의 사람들이 백 로그를 받고 때로는 시간을 내야하기 때문입니다. 특히 다른 시스템에서 데이터를 가져 오는 사람들은 데이터로드에 오랜 시간이 걸리는 경우 시작하기 전에 제품을 구매해야 할 수도 있습니다. 이러한 사람들은 데이터 전문가 인 경향이 있으며 일반 응용 프로그램 개발자보다 임시로 제품에 액세스 할 수있어보다 높은 수준의 편안함을 제공합니다. 이미 운영중인 프로덕션 서버에 갈 때 사치가 아닙니다.

데이터베이스에 대한 프로덕션 권한을 제한하는 데있어 가장 중요한 사항 중 하나는 개발자가 다른 사람이 배포 할 수있는 형식으로 작업을 수행해야한다는 것입니다. 기억력에만 의존 할 때 제품과 달리 다른 방식으로 무언가를 잊어 버렸기 때문에 즉시 수정을 시도하지 않기 때문에 작업의 질을 향상시키는 경향이 있습니다. prod 배포가 개발자가 일반적으로 한 번에 하나의 명령이 아닌 스크립트를 완전히 사용하는 경우 사고 유형을 우연히 잊어 버렸기 때문에 실수로 전체 사용자 테이블을 삭제했습니다. 찌르다. prod 데이터베이스에 대한 제한된 권한을 가진 팀은 데이터베이스 변경 사항을 소스 제어에도 저장할 수 있습니다.

Jeff Atwood가 여기에 넣은 것처럼 "뱀파이어 (프로그래머)와 늑대 인간 (Sysadmins)"에 대한 질문입니다 .

일반적으로 개발자는 다음과 같은 기능에 액세스 할 수 있습니다.

• 생산 서버
  • 없음 (SA / PM은 스키마 설정을 적용하고 최종 사용자는 초기화 데이터를 제공함)
• UAT 서버
  • 없음 (SA / PM은 스키마 설정 및 샘플 데이터 시드에 적용됨)
• 테스트 / QA 서버
  • 일반적으로 개발자는 스키마 설정 스크립트를 QA 팀에 보내고 QA는 테이블을 만듭니다.
  • 개발자는 데이터베이스에 대한 전체 액세스 권한을 갖지만 거의 변경하지 않습니다.
  • 개발자는 QA 동료가 일부 데이터를 시드 / 패치 / 삭제하도록 도울 수 있습니다
• 개발 서버 / 로컬 호스트
  • 전체 권한

개발자가 프로덕션 서버에 손대지 말아야하는 주된 이유는 문제가 발생하면 운영 팀이 책임을 지지만 개발자는 책임을지지 않기 때문입니다.

작업을 완료하는 데 필요한 최소값.

모든 개발자에게 전체 DB 액세스 권한이 부여 된 경우 데이터베이스에서 읽을 수만 있다면 화가 나거나 (혹은 취하거나 극도로 피곤하거나 ...) 심각한 피해를 입을 가능성이 훨씬 높습니다.

DB 쓰기 액세스없이 작업을 대부분 수행 할 수있는 경우 (주로 최대 일주일에 몇 번의 변경 요청을 의미 함) 실제로 쓰기 액세스가 필요하지 않습니다.

모든 작업 환경에서 2 개의 경쟁 욕구가 있습니다.

• 사람들이 스스로 문제를 해결할 수 있도록 액세스 권한을 부여하려는 욕구. 이를 통해 신속하고 셀프 서비스가 가능합니다.
• 데이터의 손상, 가동 중지 시간 또는 데이터 손실을 방지하기 위해 액세스를 제한하고 제어하려는 요구 (의도적 또는 기타).

부딪 치거나 균형을 이루는 균형을 이루는 요소 중 일부는 개발자를위한 기대치입니다. 모든 작업에서 개발자가 기대하는 모든 것에 액세스 할 수있는 곳은 개발자가 스스로 제한하는 것이 었습니다. 수행중인 작업을 알고있는 경우에만 시스템에 액세스하십시오. 즉 개발자와 sysadmin의 관점에서 무엇을하고 있는지 알 수있었습니다. 두 영역 중 어느 쪽이든 확실하지 않은 경우, 당신을 보호 할 사람이 없으면 시스템에 액세스하는 비즈니스가 없었습니다.

모르는 경우 요약하면 쉽게 재 구축 가능한 dev 시스템 이외의 시스템에 액세스 할 수 없습니다 . 알고 있다면 쉽게 재 구축 가능한 dev 시스템 이외의 시스템에 액세스해서는 안됩니다 .

개발자는 dev 데이터베이스에 완전히 액세스 할 수 있어야합니다 (이상적으로 로컬 서버를 실행해야하지만 항상 가능한 것은 아닙니다). 빌드 / QA 데이터베이스에 액세스 할 수 있지만 데이터에만 액세스 할 수 있어야합니다 (구조를 변경하려면 티켓을 승인 / 제출해야 함). 소규모 회사 / 프로젝트가 아니며 개발자도 프로덕션 지원을하지 않는 한 개발자는 프로덕션 데이터베이스에 일시적으로 액세스 할 수 없습니다.

여기서 핵심은 개발자의 책임 수준입니다. 개발자가 많은 대규모 조직에서는 QA / 테스트에 대한 읽기 전용 액세스 권한만으로 개발에 액세스 할 수 있습니다.

그러나 개발 팀에는 모든 환경에 대한 전체 액세스 권한이있는 사람이 있어야합니다. 이것은 일반적으로 수정 등을 담당하는 사람입니다. 다소 위험하지만, 개발자를 얼마나 신뢰하는지, 얼마나 빨리 고쳐야하는지, 시스템을 엉망으로 만들거나 시스템에서 정보를 공개하는 것과 관련된 위험 사이의 절충입니다. .

대규모 IT 상점에서 근무했으며 대부분의 사람들이 프로덕션에 대한 읽기 권한을 가졌습니다. 수석 개발자로서 프로덕션 데이터베이스에 대한 권한도 가지고있었습니다. 프로세스와 서류 작업 측면에서 sysadmin 및 DBA와 동일한 지침을 따라야했지만 필요한 경우 긴급 수정을 할 수도 있습니다.

대부분의 사람들이 잊어 버린 관련 문제가 있습니다. 데이터베이스를 사용하는 유일한 사람은 아닙니다! 우리는 이것을 당연한 것으로 생각하지만해서는 안됩니다. 소규모 사이트에서도 비즈니스 사람들이 보고서를 위해 데이터베이스에 대해 타사 도구를 실행하고있을 수 있습니다. 엔터프라이즈 사이트는 거의 항상 데이터베이스 테이블의 여러 사용자를 보유하게되며 '소규모'변경으로 인해 응용 프로그램이 중단 될 수 있으며 그 반대도 마찬가지입니다.

이것이 첫 번째 질문이어야합니다. 두 번째는 직원이되어야합니다. 저는 잔디를 보호했지만 실제로는 좋지 않은 시스템 관리자가있는 사이트에서 근무했습니다. (아마도 그들이 영토 인 이유 일 것입니다. 누군가 주변을 둘러 보면 많은 열을받을 것이라는 것을 알고있었습니다.) 때때로 당신은 당신이 원하는 것보다 더 많은 접근 권한을 가져야합니다.

그러나 이상적인 세상에서 나는 다른 사람들의 주장에 동의합니다. 솔직히 책임을 원하지 않기 때문에 라이브 데이터에 액세스하고 싶지 않습니다. 그것에 대해 생각해보십시오-운영 액세스 권한이 있고 위반이 발생하면 관련이 없음을 증명하는 데 많은 시간을 소비해야합니다. 개인적인 사유 등으로 인해 데이터를 정리하지 않았다는 사실을 보여 주어야 할 수도 있습니다. 정부 사이트.

테스트 그룹 시스템에 대한 쓰기 / 관리 액세스 권한도 원하지 않습니다. 프로덕션 시스템에서 어떤 작업을 수행 할 수없는 경우 테스트 시스템에서 작업을 수행하고 싶지 않습니다. 진행 상황을 파악하는 데 도움이 필요하므로 읽기 액세스는 예외입니다.

개인과 부서의 개발 시스템은 다른 이야기입니다. 그러나 실제로는 여기에서도 실제로 모든 사람이 자신의 일을하는 대신 특정 사람을 통해 모든 데이터베이스 변경을 실행하는 것이 가장 좋습니다.

"prod 데이터베이스의 개발자에게는 가능한 최소한의 권한"이라고 말하는 모든 답변에 전적으로 동의합니다. 그러나 솔직히 말하면 누가 데이터베이스를 원한다면 개발자가 데이터베이스에 대한 액세스를 거부 할 수 있습니다. 충분한 의지가 있다면 (범죄이거나 선의로) 필요한 액세스 권한을 얻게됩니다.

간단한 SQL 편집기를 응용 프로그램에 넣는 것을 누가 막을 수 있습니까? 이렇게하면 응용 프로그램의 권한으로 데이터베이스를 사용할 수 있습니다. 대부분의 경우 이것이 필요한 전부입니다. 데이터베이스가 안전하게 구성되면 개체를 만들거나 삭제할 수있는 권한이 없지만 최소한 데이터에 대한 읽기 및 쓰기 권한이 있습니다.

나는 이미 여기 사람들이 울고 있습니다. 그러나 직접 작성하지 않으면 라이브러리에 대해 생각하지 않으면 프로덕션 환경에 배포 된 응용 프로그램을 완전히 제어 할 수 없습니다. Erin이 이미 말했듯이 모든 개발자에게는 운영 담당자뿐만 아니라 프로덕션 환경도 담당하고 있습니다. 그러므로 당신의 특권을 현명하게 사용하십시오.