실수로 프로덕션 데이터베이스를 사용하지 못하게하려면 어떻게해야합니까?

최근에 개발자가 준비 복사본으로 복원해야 할 때 실수로 데이터베이스를 프로덕션으로 복원하려고했습니다. db 이름이 유사하면 (예 : CustomerName_Staging과 CustomerName_Production) 쉽게 수행 할 수 있습니다.

이상적으로는 완전히 별도의 상자에이를 가지고 있지만 비용이 많이 들며 엄밀히 말하면 사용자가 잘못된 상자에 연결해도 동일한 일이 발생하는 것을 막지 않습니다.

이는 보안 문제가 아니며, 준비 데이터베이스를 사용하는 올바른 사용자였으며 프로덕션 데이터베이스에서 수행 할 작업이있는 경우에도 그와 같은 문제가 발생했습니다. 이러한 문제를 해결하기 위해 배포 책임자에게 문의하고 싶지만 팀 규모가 충분하지 않습니다.

이를 방지하는 방법에 대한 실습, 구성 및 제어 측면에서 조언을 듣고 싶습니다.

이것이 자신이 자주하는 일이라면 자동화하십시오. 그리고 둘 다 개발자이기 때문에 일부 코드 작성은 조타실에 있어야합니다. :) 진지하게 ... 자동화하면 다음과 같은 작업을 수행 할 수 있습니다.

• 올바른 서버에서 복원하고 있는지 확인하십시오 (예 : dev-> prod 복원 없음)
• 데이터베이스의 올바른 "유형"인지 확인하십시오 (귀하의 경우 "스테이징"및 "제작").
• msdb의 백업 테이블을보고 자동으로 복원 할 백업 파악

등등. 당신은 당신의 상상력에 의해서만 제한됩니다.

나는 문제의 가정이하고 인격적으로하는 것은 반대 입니다 보안 - 그러나 나는 또한 자동화가 자신의 일을 저장하는 것입니다 동의하지 않는다. 문제부터 시작하겠습니다.

실수 로 생산에 어떤 것도 할 수 없어야합니다 !

여기에는 실수로 자동화 된 작업이 포함됩니다.

"누가 무엇을 할 수 있는지"와 같은 개념과 시스템 보안을 혼동하고 있습니다. 개발 계정은 복사본, 버전 관리 서버 및 개발자 데이터베이스에만 쓸 수 있어야합니다. 그들이 생산을 읽고 쓸 수 있다면, 고객 데이터를 훔치기 위해 해킹 당하거나 악용 될 수 있거나 (실증 한 바와 같이) 고객 데이터 손실로 잘못 취급 될 수 있습니다.

워크 플로를 정렬하여 시작해야합니다.

• 개발자 계정은 자체 사본, 버전 관리에 쓸 수 있으며 버전 관리에서 테스트 환경으로 끌어 올 수 있습니다.

• 백업 사용자는 프로덕션에서 읽고 백업 저장소에 쓸 수 있어야합니다 (적절하게 보호되어야 함).

• 프로덕션에서 다른 읽기 / 쓰기를 수행하려면 특별하고 불편한 인증 이 필요 합니다. 로그인하거나 잊어 버릴 수 없어야합니다. 여기서 물리적 액세스 제어가 유용합니다. 스마트 카드, 계정을 "무장"하기위한 플립 스위치, 동시 이중 키 액세스.

  프로덕션에 액세스하는 것이 매일해야 할 일이 아닙니다. 대부분의 작업은주의 깊게 조사한 후 테스트 플랫폼과 프로덕션에 시간 외 배치로 이루어져야합니다. 약간의 불편은 당신을 죽이지 않을 것입니다.

자동화는 솔루션의 일부 입니다.

전체 처리 시간 (VCS로 업로드, 적용 범위 확인, 테스트 서버로 가져 오기, 자동 테스트 실행, 재 인증, 백업 생성, VCS에서 가져 오기)이 긴 과정이라는 사실에 눈을 멀게하지 않습니다.

그건 벤의 대답은 당, 어디 자동화 캔 도움이됩니다. 특정 작업을 훨씬 쉽게 수행 할 수있는 다양한 스크립팅 언어가 있습니다. 바보 같은 일을 너무 쉽게해서는 안됩니다. 재 인증 단계는 여전히 발음해야하며 (위험한 경우) 생각없이 불편하고 어려워 야 합니다.

그러나 혼자서 는 자동화가 쓸모없는 것보다 나쁩니다. 적은 생각으로 더 큰 실수를하는 데 도움이됩니다.

모든 규모의 팀에 적합합니다.

팀 규모를 지적하는 것을 보았습니다. 나는 한 사람이고 사고를 일으키는 데 한 사람 만 필요하기 때문에이 문제를 해결했습니다. 오버 헤드가 있지만 그만한 가치가 있습니다. 훨씬 더 안전하고 훨씬 안전한 개발 및 프로덕션 환경으로 귀결됩니다.

내 동료 중 한 명이 이에 대한 흥미로운 접근 방식을 가지고 있습니다. 그의 생산 용 터미널 색 구성표는보기 흉하다 . 그레이와 핑크, 읽기가 어렵다. 이론적으로 그가 쓰는 것이 무엇이든 확실히 쓰려고했다.

마일리지가 다를 수 있습니다 ... 그리고 아마도 자체적으로 방탄이 거의 없다고 말할 필요는 없습니다. :)

개발자는 프로덕션 데이터베이스의 비밀번호를 알아야합니다. prod 암호는 키보드 매쉬 ( Z^kC83N*(#$Hx) 의 결과와 같이 임의적이고 기억에 남지 않아야합니다 . dev에 암호가 될 수 있습니다 $YourDog'sName또는 correct horse battery staple또는 무엇 이건.

물론, 특히 소규모 팀인 경우 클라이언트 응용 프로그램의 구성 파일을 보면 암호가 무엇인지 알 수 있습니다. 이것은 prod 암호가 있어야하는 유일한 곳입니다. 따라서 prod 암호를 얻기 위해 고의로 노력해야합니다.

(항상 항상 프로덕션 데이터베이스에 대한 특정 시점 백업이 있어야합니다. 예를 들어 MySQL의 경우 이진 로그를 증분 백업으로 아카이브합니다. PostgreSQL의 경우 미리 쓰기 로그를 아카이브하십시오. 자해 또는 기타 모든 종류의 재난.)

짧은 대답은 RBAC-역할 기반 액세스 제어입니다.

모든 환경에 대한 권한은 달라야합니다. UAC와 같은 것들과 같이 성가신 것은 특히 PROD 환경에 대한 권한입니다.

없다 결코 관계없이 조직 / 팀이 얼마나 작은의 -의 devs 생산성에 직접 액세스하는 이유는. "Dev"는 "Stage"및 "Prod"모자를 착용 할 수도 있지만 다른 환경에 맞도록 다른 자격 증명 및 프로세스가 필요합니다.

성가 시나요? 전혀. 그러나 그것은 환경을 방해하지 못하게합니까? 전혀.

빠르고 간단한 솔루션 : 개발 데이터베이스에만 액세스 할 수있는 일반 개발 작업용 계정과 실제 데이터베이스에 대한 전체 액세스 권한이있는 다른 사용자 계정을 사용하십시오. 이런 식으로, 생산을 변경하기 전에 사용중인 계정 을 적극적으로 변경 해야합니다. 실수로 실수를 방지하기에 충분해야합니다.

두 개의 웹 사이트, 두 개의 서버 또는 두 개의 전체 환경이있는 경우 동일한 접근 방식을 사용할 수 있습니다. 프로덕션에 대한 액세스 권한이없는 개발 용 사용자 계정 하나 (또는 ​​최소한 쓰기 권한이 없는 경우 ), 프로덕션 시스템에서 작업하기위한 다른 사용자 계정 ( 에스).

이는 일상적인 작업 (이메일 읽기, 웹 서핑, 티켓 추적, 작업 표 작성, 문서 작성 등)을위한 표준 비 관리자 계정과 실제로 운영 할 때 사용할 고유 한 전체 관리자 계정을 가진 sysadmin과 동일한 접근 방식입니다. 서버 및 / 또는 Active Directory.