本番データベースで誤ってジャッキングするのを防ぐにはどうすればよいですか？

つい最近、ステージングコピーに復元すべきだったときに、開発者が誤ってデータベースを本番環境に復元しようとしました。データベース名が類似している場合（CustomerName_StagingとCustomerName_Production）であれば、簡単に実行できます。

理想的には、これらを完全に別々のボックスに入れますが、それは非常にコストがかかり、厳密に言えば、ユーザーが間違ったボックスに接続した場合に同じことが起こるのを防ぐことはできません。

これ自体はセキュリティの問題ではありません。ステージングデータベースを操作するのは正しいユーザーであり、運用データベースで実行する作業があれば、それも彼の問題になります。これらの懸念を分離するために、展開担当者が必要ですが、チームはそのために十分な大きさではありません。

これを防ぐ方法について、練習、構成、および制御の観点からアドバイスを聞きたいです。

これが頻繁に行われると思われる場合は、自動化します。そして、あなたは両方の開発者なので、いくつかのコードを書くことはあなたの操舵室にあるべきです。:)まじめに...それを自動化することで、次のようなことができます：

• 正しいサーバーで復元していることを確認します（つまり、dev-> prodの復元はありません）
• データベースの正しい「タイプ」であることを確認します（あなたの場合、「ステージング」と「プロダクション」）
• msdbのバックアップテーブルを見て、自動的に復元するバックアップを見つけます。

など。あなたの想像力によってのみ制限されます。

私は質問の前提に同意しません—これはセキュリティです— しかし、自動化がそれ自体で一日を節約することになることにも同意しません。私は問題から始めます：

本番環境に対して誤って何かをすることはできません！

それには、自動化されたものを誤って実行することが含まれます。

システムのセキュリティを「誰が何をすることを許可されているか」などの概念と混同しています。開発アカウントは、そのコピー、バージョン管理サーバー、および開発データベースにのみ書き込みができる必要があります。プロダクションの読み取り/書き込みができる場合、ハッキングされて顧客データを盗むために悪用されたり、（実証したように）顧客データを失ってしまう可能性があります。

ワークフローを整理することから始める必要があります。

• 開発者アカウントは、独自のコピーに書き込み、バージョン管理を行い、バージョン管理からテスト環境にプルできる必要があります。

• バックアップユーザーは、運用環境からの読み取りとバックアップストアへの書き込みのみを行う必要があります（適切に保護する必要があります）。

• 本番環境で他の読み取り/書き込みを行うには、特別で不便な認証が必要です。ログインしたり忘れたりしてはいけません。ここでは物理的なアクセス制御が便利です。スマートカード、アカウントを「アーム」するフリップスイッチ、同時ターンデュアルキーアクセス。

  本番環境へのアクセスは、毎日行う必要があるものではありません。作業の大部分は、テストプラットフォームで行われ、綿密な精査の後、本番環境への時間外の展開が行われます。少し不便でもあなたを殺すことはありません。

自動化はソリューションの一部です。

完全なターンアラウンド（VCSへのアップロード、カバレッジの確認、テストサーバーへのプル、自動テストの実行、再認証、バックアップの作成、VCSからのプル）が長いプロセスであるという事実に目をつぶっていません。

それはだベンの答えごとに、どこオートメーション缶の助け。特定のタスクをはるかに簡単に実行できるさまざまなスクリプト言語があります。バカなことをしすぎないようにしてください。あなたの再認証手順は、まだ彼らは（と危険な場合）と発音しなければならない必要がある思考せずに行うことが不便と難しいかも。

しかし、単独では、自動化は役に立たないよりも悪いです。それはあなたがより少ない考えでより大きな間違いをするのを助けるでしょう。

あらゆる規模のチームに適しています。

チームの規模を指摘していることに気付きました。私は一人の男であり、事故に遭うのはたった1人で済むので、私はこれを経験しました。オーバーヘッドがありますが、それだけの価値があります。最終的には、はるかに安全で安全な開発および運用環境になります。

私の同僚の一人は、これに対して興味深いアプローチをしています。彼の制作の最終的な配色はfuいです。灰色でピンク色で読みにくい。理論的には、彼が書くものは何でも、彼が本当に書くことを意図したものであることが保証されている。

あなたの走行距離は異なる場合があります...そして、おそらくそれだけでは防弾ではないと言う必要はありません。:)

開発者は、本番データベースへのパスワードを知らないでください。prodのパスワードはランダムで覚えやすいものではなく、キーボードマッシングの結果（Z^kC83N*(#$Hx）のようなものでなければなりません。あなたのdevのパスワードが可能$YourDog'sNameか、correct horse battery stapleまたは何でも。

確かに、特に小さなチームの場合は、クライアントアプリケーションの構成ファイルを見ることで、パスワードが何であるかを知ることができます。prodパスワードが存在する唯一の場所です。これにより、prodパスワードを取得するための意図的な努力が必要になります。

（いつものように、実稼働データベースのポイントインタイムバックアップが必要です。たとえば、MySQLの場合、バイナリログを増分バックアップとしてアーカイブします。PostgreSQLの場合、先行書き込みログをアーカイブします。自己災害またはその他のあらゆる種類の災害）

短い答えはRBAC-ロールベースのアクセス制御です。

すべての環境に対するアクセス許可は異なる必要があります。UACのようなものと同じくらいうっとうしいものですが、特にPROD環境の場合は必要です。

がある 開発者がProdに直接アクセスできる理由決してません-組織/チームの規模にかかわらず。「Dev」も「Stage」と「Prod」の帽子をかぶっていますが、異なる環境にアクセスするには異なるクレデンシャルとプロセスが必要です。

迷惑ですか？絶対に。しかし、それはあなたの環境を壊すのを防ぎますか？絶対に。

すばやく簡単なソリューション：2つの異なるユーザーアカウントを使用します。1つは開発データベースにのみアクセスする通常の開発作業用で、もう1つは運用データベースで実際に操作し、完全にアクセスできる別のアカウントです。このように、本番環境で変更を加える前に、使用しているアカウントを積極的に変更する必要があります。これは、偶発的なミスを防ぐのに十分なはずです。

2つのWebサイト、2つのサーバー、または2つの環境がある場合、同じアプローチを使用できます。1つは開発用のユーザーアカウント、運用環境へのアクセス権（または少なくとも書き込みアクセス権なし）、運用システムで作業するための別のユーザーアカウント（ s）。

これは、日常業務（電子メールの読み取り、Webサーフィン、チケットの追跡、タイムシートの提出、ドキュメントの作成など）のための標準の非管理者アカウントと、実際に操作するときに使用される個別の完全管理者アカウントを持つシステム管理者と同じアプローチですサーバーおよび/またはActive Directory上。