開発者は本番データベースにクエリを実行できますか？
開発者に（SELECT /読み取り専用）本番データベースをクエリする権限を与える必要がありますか？以前私が働いていた場所、開発チームにはdb_datareaderロール;私が今働いているところでは、開発チームは本番インスタンスに接続することさえできません。
テストインスタンスの1つは、週に1回本番バックアップから復元された本番環境のコピーであるため、開発者が実際にデータを表示しても問題はありません。
開発者がプロダクションをクエリできないようにする理由は何ですか（機密データの読み取りへのアクセスを単に望まないことを除いて）？
それは、開発者にサポートの責任があるかどうかに本当に依存します。 3行目のサポートが必要な場合は、本番データベースを確認する必要があります。
一般に、実際に実行する必要がない限り、運用サーバーで何かを実行することはお勧めしません。
ほとんどの開発目的では、本番データベースのミラーまたはスナップショットで十分であり、おそらく本番データベースよりも優れています。統合に関係することを行う場合は、それらの内容を制御できる安定したデータベース環境が必要になります。調整を伴うものには、制御された時点を確認する機能も必要です。
プロダクションミラー環境がないか、開発者のためにプロダクションデータのコピーをどこかに置く手段がないことが問題である場合、これはやや異なる質問です。その場合、開発者は本当に少なくとも1つのミラー環境を必要とします。データの何が問題なのかわからない場合は、トラブルシューティングするのが難しいです。
番号。
開発者は、次の理由で本番データベースシステムにアクセスできません。
可用性とパフォーマンス：データベースへの読み取り専用権限は無害ではありません。不適切に記述されたクエリでは、次のことが可能です。
- テーブルをロックし、他の重要なプロセスをブロックします。
- データキャッシュを破棄し、他のプロセスにディスクからデータを再度読み込ませる。
- ストレージレイヤーに課税し、そのストレージを共有する他のサービスに影響を与えます。
セキュリティ：本番データベースには次のような機密情報が含まれている可能性があります：
- パスワードハッシュ
- 課金情報
- その他の個人を特定できる情報
この情報に絶対にアクセスする必要がある人だけがそれを持っているべきです。よく組織された会社では、開発者はそれらの人々の中にいません。さらに、開発者がこのデータで本番システムにアクセスできる場合、会社はPCIおよびSOXコンプライアンスに失敗します。
この理由は明白です。開発者の開発作業は、公開される前に多くの手間がかかります。プロダクションに直接アクセスできる悪意のある開発者がプロダクションデータを盗んだり、ライブデータベースをひどく悪用したりしないようにするにはどうすればよいでしょうか。
「しかし、それはDBAにも当てはまります。彼らはそれを行うことができます！」丁度。 責任を持って可能な限り少ないスーパーユーザーが必要です。
はい。
開発者は本番システムにアクセスする必要があります。
私の会社には、本番データベースを扱う4つのチームがあります。彼らです：
- データベースのスキーマとコードを設計および作成する開発者。運用中のデータベースにはアクセスできません。ただし、管理者やサポート担当者と一緒に座って、ライブで何かを見ることを支援することもあります。
- 管理者は、運用環境でデータベースを展開、監視、および管理します。
- サポート担当者は、時間に敏感な製品の問題を調査し、修正を開発できるように開発者にフィードバックを提供します。
- ビジネスインテリジェンスの人々は、データベースの定期的に更新されたコピー、または慎重に記述されたQA抽出（通常は管理者が設計）を使用して、本番データベースからデータを抽出します。 ）。
これらの他のグループに特定の欠陥がある場合は、開発者に本番アクセスを許可することが適切です。
例えば：
- サポートチームはありません。時間に敏感な本番環境の問題をデバッグする場所を誰が知っているのでしょうか。あなたの開発者。それらに「 ガラスを割る 」アクセスを許可します。
- BIチームがありません。管理者がレポートや抽出物を持っていないか、何もしません。役員が毎朝見るレポートのトラブルシューティングを行うのはだれですか。あなたの開発者。これらのレポートと抽出をデバッグするための制限付きアクセスを許可します。
- あなたには管理チームがありません。あなたは非常に小さな会社または新興企業ですので、「偶発的なDBA」に挨拶してください。開発者は管理者を兼ねているため、本番環境へのフルアクセスが必要です。
パフォーマンスが大きな理由になります。
データを変更できないからといって、サーバーに影響を与えることができないわけではありません。クエリの記述が不十分だと、本番環境がひどくなり、他の問題（tempdbオーバーフローなど）が発生する可能性があります。
SELECT *
FROM BigTable A, OtherBigTable B
ORDER BY Somecolumn
それは災害のレシピです。これは、order byを指定したデカルト積であることに注意してください。つまり、tempDBでソートされます。
原則は「最小限の特権」と「知る必要がある」です。開発者はこのテストに合格しますか？
特に監査人またはサーバンヌスオクスリーがノックするとき。
次に、私の次の仮定：開発者は愚かです。それで、彼らが3行目のサポートについて発言する必要がある場合、誰がthenがそれを必要とするのでしょうか？ Webモンキーは通常、サポートしませんが、データベースタイプはサポートします。
それでは、アクセスは永続的に必要ですか？ SQLログインまたはサインオフが必要な代替のWindowsアカウントを使用して、「ブレイクグラス」アクセスが可能です。私たちの場合、それを承認したのはデータ所有者（テクノロジーに精通したビジネスパーソンの1人）とITマネージャーでした。
私はhaveプロダクションに対してクエリを実行したりクエリを実行したりしましたそれを削除するは無知のためです。それを言って、開発者は彼らの行動に責任を負わなければなりません：もし彼らがサーバーを倒した場合、彼らはそれに応じて苦しむべきです。ある事件の後で誰かが降格した...
もちろん、これらは合理的なサイズのショップを想定しています。帽子をかぶるほど、職務の分離が少なくなります
また、開発者が最近のデータに対してクエリを実行できる環境はありますか？私の最後のショップでは、prodを毎晩テストサーバーに復元してこれを提供していました。
答えは、多くのITと同様に、「状況によって異なります」と思います。
大規模なERP機密性の高い会社と顧客の情報が多数含まれるデータベース？おそらくない（セキュリティとパフォーマンスの両方の理由から）。
ドーナツとピザの資金への貢献を追跡するAccessフロントエンドを備えた部門別の5 MBデータベース？少なくとも読み取り専用アクセスについては、大きな違いはありません。
確かに、最初の例は2番目の例よりもはるかに一般的ですが、これらの違いは、これらのタイプのポリシー決定を担当する場合に注意する必要があります。しかし、逆に言えば、5 MBのドーナツとピザのファンドのデータベースが、50 GBの部品番号/顧客のクレジットカード番号/誰が何を知っているかを、スコープクリープしてその速さを測ることができるのは驚くべきことです。それを許せば他のデータベース。
通常の24時間年中無休OLTP環境では、通常の開発者が本番環境で許可されるべきではありません。期間！場合によっては、特定の理由が表示される場合、リクエストに応じてアクセス許可を付与できます。しかし、通常は違います。
これには多くの理由があります。
SELECT *につながる大きなテーブルから：
- パフォーマンスの問題（デカルト製品）;
- 最終的にサイトをひざまずくような問題をブロックします。
- レプリケーションを停止させるブロッキングチェーン。
- tempDBドライブを満たした大きなデータセットを注文する完全な狂気を引き起こした:-)！
- その夜の生産を担当するDBAの高血圧。
機密データの読み取り（開発者がクレジットカード情報やユーザーの個人情報にアクセスできないようにする必要があります）;
さらに多くの理由があると確信しています。
- セキュリティ：機密情報は、開発者が利用できるようにするときに無害化される可能性があります。
- パラノイア：一部の人は、選択アクセスだけでデータを台無しにできると思っているかもしれません。
- パフォーマンス：クエリの実行にはいくつかのリソースが必要です。開発者がコードを書くときに、開発者が完璧であるとは言えません。
検討する項目の組み合わせ
- データは機密ですか？
- プログラマーはコアの信頼できるチームの一部ですか、それともオフショアチームですか？
- パフォーマンスに影響を与えるという観点から、照会されるデータの規模はどのくらいですか？
- プロジェクトの規模や関与する費用はどのくらいですか？
- 稼働時間はどれほど重要ですか？
少額必要なプロセスは少なくて済み、開発の流れが速くなります。
高額より多くのプロセスが必要であり、開発プラクティスのより厳しい基準が必要です。
あなたの実践をあなたがしていることに適応させてください。
私は非常に大きな会社の開発者として働いています。あらゆる種類のサポートを行うすべての開発者（基本的にはすべて）は、関連する本番データベースにアクセスできます。私は私の特定のチームについてのみ話すことができますが、なぜ私たちがアクセスできるのかを説明します。
- 日々の処理を監視するには、リアルタイムアクセスが必要です。 （ダッシュボードを使用している間は、物事を詳細に監視できる必要があります。ダッシュボードにこの機能があると便利ですが、実用的ではないことがわかりました。）
- 遅延は大きな影響を与える可能性があるため、本番環境の障害を調査するにはリアルタイムアクセスが必要です。 （私はここで私たちの失敗について議論するつもりはありません。それらはあらゆる種類のものです）
- 多くの場合、ビジネスユーザー向けのカスタムレポートを作成する必要があり、この情報は最新である必要があります。 （dbaにはこれを行う時間がないし、それらを待つ時間もありません。理想的ではありませんが。）
- 本番DDL/DMLデプロイメント/パッチの検証を行う必要があります。 （DBAはそれらを展開しますが、それがどのように構造化されるべきかを知っています。データベース構造についてはDBAよりも知っています。奇妙かもしれませんが、私たちのビジネスは非常に複雑であるため、データベースは非常に複雑です。）
パフォーマンスが問題です。スローダウンを引き起こしている開発者がいます。ただし、これらは分離されたインスタンスであり、SQLはパフォーマンスが非常に高いため、開発者がクエリの影響を理解していないことはまれです。
この質問をするためには、彼らが現在アクセスできないと仮定する必要があります。組織がソフトウェアを開発していて、これが顧客の問題のトラブルシューティングのためであり、顧客がデータベースのコピーを提供している場合は、「はい」です。それ以外の場合は、開発者を本番環境から除外し、研究ニーズのために代替環境を作成することを推奨します。歯磨き粉がチューブから出たら、元に戻すのは難しい。
正当化の負担はアクセスを必要とするものにあるべきだと私は同意します。通常、私が相談した環境では、小規模な環境であり、サポート担当者である本番システムにアクセスしました。私はサポートをサポートしていたバックアップなどにアクセスし、本番データに（専任のサポート開発者を通じて）間接的にアクセスしました。
重要なのは、すべてをスムーズに実行し続けるために必要なときにこの機能が必要であり、機能していないものに関する財務担当者の質問に答える必要があるということです。その場合、常に1日前のデータから作業することはできません。一方、アクセスが多いほど、アクセスは悪化します。通常、私はコンサルタントとして、必要でない限り、この種のアクセス権を取得することは避けます。私は財務データベースに取り組んでいるので、最後に自分が請求書を入力したと非難されます:-D。
一方、アクセスが必要ない場合は、アクセスできません。開発者はおそらくこれが正しく処理されていることを確認するためにオンフックであるため、私は機密データの引数を実際に購入しません（バグレポートが届いたときに実際に保存されているものを見ないで確認するのは非常に困難です）。開発者のアプリが保存しているデータを見ることが開発者に信頼できない場合は、開発者を雇ってアプリを作成しないでください。開発者がデータを難読化してメールで送信する方法は多すぎるため、確信が持てません。 MACコントロールはここで役立ちますが、実装はまだかなり複雑です。
私の側からの大きな問題は、書き込みアクセスに関係しています。その場合、開発者がアクセス権を持たない場合、その開発者には書き込みアクセス権がありません。ブックの整合性を確認したい場合は、書き込みアクセスをできるだけ少ない人に維持したいとします。監査証跡は、開発者がアクセスできない場合の検証がはるかに簡単です。開発者が読み取りアクセス権を持っている場合、書き込みアクセス権を与えることができる特権エスカレーション接続があったかどうかについて常に質問があります（おそらくストアードプロシージャSQLインジェクション？）。ステージング環境にアクセスできたとき、クライアントの課金情報に完全にアクセスできることがよくありました。ただし、機能するステージング環境がある場合は、必要がない限り、通常は積極的にnotに本番環境へのアクセス権を要求します。
もちろん、これは完璧ではありません。開発者は、まだ簡単に検出できない可能性があるアプリケーションにバックドアを組み込むことができますが、バックアップデータが前日から利用可能であることを考えると、これは懸念事項であるように思えます。
お役に立てれば。
編集：私が働いた大規模な環境でそれを追加するだけで、私は、財務システムの数日から数か月前までのフルバックアップデータにアクセスできました。これはalwaysで十分に機能し、機能しなくなったのは、財務担当者が本番環境と一致するように新しいデータでテストする機能が必要になったときだけです。
アクセスできないことは良いことであり、開発者や他の人が誤ってデータを破壊したり表示したりしないように保護する方法です。これにより、企業は法律を破ることからも保護されます（つまり、Hipaa違反とプライバシーの懸念）
開発者が本番環境に実際にアクセスする必要はありません。厳しいバグを再現できない場合は、開発者の観点から見ると簡単です。
ただし、開発者はミニダンプまたはログファイルを入れ、PDBシンボルファイルを使用してバグを再現できます。
データをテスト環境にダウンさせる必要がある場合、ある種のプロセスではデータをスクラブして余分な作業を作成するのが一般的です。
プロダクションと呼んでいるもので使用されているデータベースソフトウェアによっては、開発者がデータベースにアクセスするために新しいライセンスが必要になる場合があります。
会社が生産の問題をデバッグまたは調査するためのツールを提供していない場合は、生産データにアクセスできないためではありません。
データは、ほとんどのアプリケーションで最も価値のある部分です。
パフォーマンスが理由の1つかもしれません。
多くの場合、開発者のクエリは非効率的であり、適切に調整されるまで、過度のロックまたはリソースの使用を引き起こします。
本番システムは、開発者が実験するのに適した場所ではありません。
それは、DBAと、開発者が自信を持っているかどうかに依存します。通常、開発者には、本番データベースに対するクエリ（読み取り）権限が与えられます。経験則として、開発者すべきはtest/devデータベースでのみ機能します。
課題は、ほとんどのソフトウェアアプリケーションがデータ駆動型であることです。したがって、アプリケーションの問題を修正しようとしているときは、それを引き起こしているデータを実際に確認する必要があります。したがって、開発者は本当に何らかの形のアクセスを必要とします。
SQLログインを使用して、テーブルへの読み取り専用アクセスのみを許可することは素晴らしいことです。しかし、何が原因で、20個の結合を持つクエリを作成したり、数百万のレコードを持つテーブルからSELECT *を実行したりできないのでしょうか。これらのクエリは、データベースとストレージのパフォーマンスを誤って停止する可能性があります。
私の会社Stackifyは、これを解決するための賢い方法を考え出しました。開発者はソフトウェアを介してクエリを実行できます。クエリプランを使用して、それが単なるSELECTステートメントであること、およびクエリの推定コストが低く、数個のレコードのみが返されることを確認します。このように彼らは多くの害を及ぼすことはできません。また、実行するすべてのクエリを監査します。
これは私たちが提供するものの1つにすぎません。 http://www.Stackify.com で私たちをチェックして、 DevOpsサポート ソリューションの詳細を確認してください。
はい。場合によっては、開発者を含むユーザーの一部のサブセットに、運用データのクエリへのある程度のアクセスを許可することが理にかなっています。ただし、2つの理由により、適切な制限を設ける必要があります。まず、DBAとして、すべてのユーザーが必要とするサービスのレベルを保証するために最善を尽くす必要があります。また、大量の削除やビジネスルールの違反など、意図しない不正なクエリを防止する必要があります。言うまでもなく、適切なセキュリティ管理を実施する必要があります。
データベーステーブルへのアドホッククエリを直接許可しない理由が何であれ、ビューやストアドプロシージャへのクエリを許可する場合があります。データベースのアクセス許可を使用すると、テーブルに対するSELECTクエリを直接禁止し、特定のユーザーがアクセスできるビューとストアドプロシージャを制限することもできます。この方法は、ユーザーベースに柔軟性を与えるだけでなく、正しく実装されたときにデータの整合性と実現可能性も保護します。
当社では、本番サービスに依存しない本番データベースの読み取り専用スレーブを維持しています。開発者には、本番データにアクセスするためのアクセス権を付与します。機密データ（顧客情報、支払い情報など）がある場合は、それらのテーブルの複製を制限し、サンプルデータテーブルをスレーブサーバーに保持します。
いいえ。
これが、開発/テスト/ UATサーバーを備えている理由です。本番環境のデータをテスト環境にコピーして、開発者はテストを進めることができます。選択クエリは、運用環境の場合にも非常に有害な場合があります。負荷が増加し、ピーク時にはパフォーマンス全体が低下する可能性があります。
必要な情報はすべて、DBAを経由して送信する必要があります。DBAは、必要なものを実行して（選択）、結果を送信できます。それが私たちの環境でのやり方です。