開発者は、SELECT本番データベースを照会（/読み取り専用）する許可を与えられるべきですか？私が以前働いていた場所では、開発チームがdb_datareader役割を果たしていました。私が現在働いている場所では、開発チームは実稼働インスタンスに接続することさえできません。

テストインスタンスの1つは、1週間に1回、運用環境のバックアップから復元された運用環境のコピーです。したがって、開発者が実際にデータを表示しても問題はありません。

開発者がプロ​​ダクションにクエリを許可しない理由は何ですか（単に機密データの読み取りにアクセス権を持たせたくない場合を除く）。

開発者がサポート責任を負うかどうかに大きく依存します。3行目のサポートを求めている場合は、おそらく運用データベースを調べてこれを行う必要があります。

一般に、実稼働サーバーで何かを行う必要がある場合を除き、実稼働サーバーで何かを行うことは悪い考えです。

ほとんどの開発目的では、運用データベースのミラーまたはスナップショットで十分であり、おそらく運用中の運用データベースよりも優れています。統合に関係する何かをしている場合、その中身を制御できる安定したデータベース環境が必要になります。和解を伴うものには、制御された時点を見る能力も必要です。

問題が実稼働ミラー環境がないこと、または実稼働データのコピーを開発者のどこかに置く手段がない場合、これはやや異なる質問です。その場合、開発者は少なくとも1つのミラー環境を本当に必要とします。データの問題がわからない場合は、トラブルシューティングが困難です。

番号。

次の理由により、開発者は本番データベースシステムにアクセスできません。

1. 可用性とパフォーマンス：データベースへの読み取り専用権限は無害ではありません。不完全に記述されたクエリは次のことができます。

   1. テーブルをロックし、他の重要なプロセスをブロックします。
   2. データキャッシュを破棄し、他のプロセスにディスクからのデータの再読み込みを強制します。
   3. ストレージ層に課税し、そのストレージを共有する他のサービスに影響を与えます。

2. セキュリティ：本番データベースには、次のような機密情報が含まれる場合があります。

   • パスワードハッシュ
   • 課金情報
   • その他の個人情報

   この情報に絶対にアクセスする必要がある人だけがそれを持っているべきです。よく組織された会社では、開発者はそれらの人々の間ではありません。さらに、開発者がこのデータを使用して本番システムにアクセスできる場合、会社はPCIおよびSOXコンプライアンスに失敗します。

   この理由は明らかです。開発者の開発作業は、公開される前に多くの手を経て行われます。実稼働環境に直接アクセスする悪意のある開発者が、実稼働環境のデータを盗んだり、ライブデータベースを危険にさらしたりするのを阻止するにはどうすればよいですか？

   「しかし、それはDBAにも当てはまります！まさに。責任を持ってできる限り少ない数のスーパーユーザーが必要です。

はい。

開発者は本番システムにアクセスできる必要があります。

私の会社には、実稼働データベースを扱う4つのチームがあります。彼らです：

1. データベースのスキーマとコードを設計および作成する開発者。運用中のデータベースにはアクセスできません。ただし、管理者またはサポート担当者と一緒に座って、ライブで何かを確認できるようにすることもあります。
2. 管理者は、展開、監視、および生産にデータベースを管理します。
3. 時間に敏感な本番の問題を調査し、修正を開発できるように開発者にフィードバックを提供する人々をサポートします。
4. これらのデータベースの定期的に更新されたコピーまたは慎重に作成され、QAされた抽出（通常は管理者によって設計された）のいずれかを使用して本番データベースからデータを抽出するビジネスインテリジェンスの人々。

これらの他のグループに特定の欠陥がある場合は、開発者に本番アクセスを許可することが適切です。

例えば：

• サポートチームはありません。その時間に敏感な本番の問題をデバッグするためにどこを調べればいいのか、誰が知るでしょうか？開発者。「ガラスを破る」アクセスを許可します。
• BIチームはありません。管理者は、レポートや抽出物とは何の関係も持ちません。エグゼクティブが毎朝表示するレポートのトラブルシューティングを行うのは誰ですか？開発者。これらのレポートと抽出をデバッグするための制限付きアクセスを許可します。
• 管理チームはありません。あなたは非常に小さな会社またはスタートアップ企業にいるので、「偶発的なDBA」に挨拶してください。開発者は管理者を兼ねているため、実稼働環境へのフルアクセスが必要です。

パフォーマンスが大きな理由になります。

データを変更できないからといって、サーバーに影響を与えられないわけではありません。クエリの記述が適切でないと、実稼働環境がひどくなり、他の問題（tempdbのオーバーフローなど）が発生する可能性があります。

SELECT *
FROM BigTable A, OtherBigTable B
ORDER BY Somecolumn

それは災害のレシピです。これは、order byのデカルト積であることに注意してください。つまり、tempDBでソートされます。

原則は「最小限の特権」と「知る必要がある」です。開発者はこのテストに合格しますか？
特に、監査役またはSarbannes-Oxleyがノックするとき。

それから、私の次の仮定：開発者は愚かです。それで、もし彼らが3行目のサポートを言う必要があるなら、誰がそれを必要としますか？Webモンキーは通常サポートしませんが、データベースタイプはサポートすることが期待されている場合はサポートします。

次に、アクセスは永続的に必要ですか？SQLログインまたはサインオフを必要とする別のWindowsアカウントを使用して、「ブレイクグラス」アクセスが可能です。私たちの場合、それはデータの所有者（一部の技術に精通したビジネスマン）とそれを承認するITマネージャーでした。

私がしている開発者はに対してテストや生産上のクエリを実行して見てそれを取るために無知で。そうは言っても、開発者は自分の行動に責任を負うべきです。サーバーをダウンさせると、それに応じて苦労することになります。ある事件の後、誰かを降格させました...

もちろん、これらは合理的なサイズのショップを想定しています。帽子を着用するほど、職務の分離が少なくなります

また、開発者が最近のデータに対してクエリを実行できる環境はありますか？私の最後の店では、prodはこれを提供するために毎晩テストサーバーに復元されました。

答えは、ITの多くのものと同様に、「それは依存する」だと思います。

企業や顧客の機密情報がたくさんある大規模なERPデータベース？おそらくそうではありません（セキュリティとパフォーマンスの両方の理由から）。

ドーナツとピザの資金への貢献を追跡するAccessフロントエンドを備えた部門5 MBのデータベースですか？少なくとも読み取り専用アクセスについては、大きな違いはありません。

確かに、最初の例は2番目の例よりもはるかに一般的ですが、これらのタイプのポリシー決定を担当する場合は、これらの違いに注意する必要があります。しかし、逆に、5 MBのドーナツとピザの資金のデータベースが50 GBの部品番号/顧客のクレジットカード番号/誰が何を知っているのか、どのくらいの速さで範囲クリープできるかは驚くべきことです。それ以外の場合はデータベース。

通常の年中無休のOLTP環境では、通常の開発者を本番環境で使用することはできません。期間！時々、特定の理由が表示される場合は、リクエストに応じて許可が与えられる可能性があります。しかし、通常ではありません。

これには多くの理由があります。

• SELECT *につながる大きなテーブルから：

  • パフォーマンスの問題（デカルト製品）;
  • 最終的にサイトをひざまずかせた問題をブロックします。
  • レプリケーションをハングさせるブロッキングチェーン。
  • TempDBドライブをいっぱいにした大量のデータを注文します。完全な狂気を引き起こしました:-)！
  • その夜の生産を担当するDBAの高血圧。

• 機密データの読み取り（開発者がクレジットカード情報にアクセスしたり、ユーザーの個人情報を取得したりしないでください）。

さらに多くの理由があると確信しています。

• セキュリティ：開発者が利用できるようにするときにサニタイズされる機密情報が存在する場合があります。
• パラノイア：一部の人は、選択アクセスだけでデータを台無しにできると考えるかもしれません。
• パフォーマンス：クエリを実行するにはいくつかのリソースが必要であり、開発者がコードを書くときに完璧だとは言えません。

考慮すべき項目のカップル

• データは機密ですか？
• プログラマーは信頼できるコアチームのメンバーですか、それともオフショアチームのメンバーですか？
• パフォーマンスへの影響という観点から、クエリ対象のデータの規模はどのくらいですか？
• プロジェクトの規模はどのくらいですか？
• 稼働時間はどれほど重要ですか？

ドルが小さいほど、プロセスの必要性が少なくなり、開発の流れが速くなります。

より大きなドルはより多くのプロセスを必要とし、開発慣行のより厳しい基準が必要です。

あなたの習慣をあなたがしていることに適応させてください。

私は大企業の開発者として働いています。あらゆる種類のサポートを行うすべての開発者（基本的にはすべて）は、関連する運用データベースにアクセスできます。特定のチームについてのみ話すことができますが、なぜアクセスできるのかを説明します。

1. 毎日の処理を監視するには、リアルタイムアクセスが必要です。（ダッシュボードはありますが、物事を詳細に監視できるようにする必要があります。この機能をダッシュ​​ボードに追加しておくと便利ですが、実用的ではないことがわかりました。）
2. 遅延は大きな影響を与える可能性があるため、実稼働の障害を調査するにはリアルタイムアクセスが必要です。（ここで私たちの失敗について議論するつもりはありません。それらはあらゆる種類のものがあります）
3. 多くの場合、ビジネスユーザー向けにカスタムレポートを作成する必要があり、この情報は最新である必要があります。（dbaにはこれを行う時間がなく、私たちはそれらを待つ時間もありません。もちろん理想的ではありません。）
4. 本番DDL / DMLデプロイメント/パッチの検証を行う必要があります。（DBAはそれらを展開しますが、その構造を知っているのは私たちだけです。データベース構造についてはDBAよりも知っています。ここでは奇妙かもしれませんが、業務が非常に複雑であるため、outデータベースは非常に複雑です。）

パフォーマンスが問題です。スローダウンを引き起こす開発者がいます。ただし、これらは分離されたインスタンスであり、SQLのパフォーマンスが非常に高いため、開発者がクエリの影響を理解できないことはまれです。

この質問に答えるには、現在アクセスできないと仮定する必要があります。組織がソフトウェアを開発しており、これが顧客の問題のトラブルシューティングを目的としており、顧客がデータベースのコピーを提供している場合、「はい」です。それ以外の場合は、開発者を本番環境から除外し、研究ニーズに合わせて代替環境を作成することを推奨します。歯磨き粉がチューブから出たら、元に戻すのは難しいです。

正当化の負担は、アクセスを必要とするものにあるべきだということに同意します。通常、私が相談した環境では、小規模な環境であり、サポート担当者である本番システムにアクセスできました。私は、サポートをサポートしていたバックアップなどにアクセスし、本番データに間接的にアクセスしました（専任のサポート開発者を介して）。

重要なのは、すべてがスムーズに実行されるようにするためにフックにいるときにこのアクセスが必要であり、財務担当者の何かが機能していないという質問に答えなければならないということです。その場合、1日前のデータからでも常に作業できるとは限りません。一方、アクセスが多いほど悪化します。通常、コンサルタントとして、必要でない限り、この種のアクセスを回避する傾向があります。私は金融データベースに取り組んでいるので、私が最後に望むことは、自分の請求書を入力したとして非難されることです。

一方、アクセスが必要ない場合はアクセスできません。開発者はおそらくこれが正しく処理されることを確認するためにフックにいるので、機密データの引数を実際に購入することはありません（バグレポートが届いたときに実際に保存されているものを見ずに確認することは非常に困難です）。開発者のアプリが保存しているデータを見ることを開発者に信頼できない場合、開発者を雇ってアプリを書くべきではありません。開発者がデータを難読化してメールで送信する方法は多すぎるため、確実ではありません。MAC制御はここで役立ちますが、実装するのはまだかなり複雑です。

私の側からの大きな問題は、書き込みアクセスに関係しています。開発者にアクセス権がない場合、つまり、開発者には書き込みアクセス権がありません。書籍の整合性を検証する場合は、できる限り少数のユーザーに書き込みアクセスを許可します。開発者がアクセスできない場合、監査証跡の検証ははるかに簡単です。開発者が読み取りアクセス権を持っている場合は、書き込みアクセス権を付与できる特権エスカレーションアタッチ（ストアドプロシージャのSQLインジェクションの可能性がありますか）があるかどうかについて、常に質問があります。ステージング環境にアクセスできたときに、クライアントの請求情報にフルアクセスできることがよくありました。ただし、ステージング環境が機能する場合は、必要でない限り、通常は実稼働環境にアクセスできないよう積極的に依頼します。

したがって、これはもちろん完璧ではありません。開発者はアプリケーションにバックドアを組み込むこともできますが、これは容易に検出できない場合がありますが、バックアップデータが前日から利用可能であるという事実を考えると、このアプローチは合理的なアプローチです。

お役に立てれば。

編集：私が働いていた大規模な環境でそれを追加するだけで、私はしばしば金融システムの数日から数か月前に及ぶフルバックアップデータにアクセスできました。これは常に私の仕事にとって十分であり、故障したのは、財務担当者が本番と一致させるために新しいデータでテストする機能を必要としたときだけでした。

アクセス権がないことは良いことであり、誤ってデータを破損したり表示したりしないように開発者などを保護する方法です。また、これにより、企業は法律に違反することから保護されます（つまり、Hipaa違反とプライバシーの懸念）

開発者は実稼働環境に実際にアクセスする必要はありません。難しいバグを再現できない場合、開発者の観点からは簡単です。

ただし、開発者はミニダンプまたはログファイルを作成し、PDBシンボルファイルを使用してバグを再現できます。

データをテスト環境にダウンさせる必要がある場合、通常、何らかのプロセスでデータをスクラブして余分な作業を作成することがあります。

本番と呼んでいるもので使用されているデータベースソフトウェアによっては、開発者がデータベースにアクセスするために新しいライセンスが必要になる場合があります。

会社が生産の問題をデバッグまたは調査するためのツールを提供していないのは、生産データにアクセスできないからではありません。

データは、ほとんどのアプリケーションの最も貴重な部分です！

パフォーマンスが理由の1つである可能性があります。

開発者のクエリは非効率的であることが多く、適切に調整されるまで過度のロックやリソースの使用を引き起こします。

実稼働システムは、開発者が実験するのに適した場所ではありません。

DBAと、開発者にどのように自信を持っているかによります。通常、開発者には実稼働データベースへのクエリ（読み取り）特権が与えられます。経験則として、開発者は test / devデータベースでのみ作業する必要があります。

課題は、ほとんどのソフトウェアアプリケーションがデータ駆動型であることです。そのため、アプリケーションの問題を修正しようとするとき、実際にそれを駆動しているデータを確認する必要があります。そのため、開発者は何らかの形でアクセスする必要があります。

SQLログインを使用して、テーブルへの読み取り専用アクセスのみを許可するのは素晴らしいことです。しかし、20の結合を持つクエリを作成したり、何百万ものレコードを持つテーブルからSELECT *を実行したりするのを妨げるものは何ですか？これらのクエリは、誤ってデータベースとストレージのパフォーマンスを低下させる可能性があります。

私の会社Stackifyは、これを解決する賢い方法を思いつきました。開発者はソフトウェアを使用してクエリを実行できます。クエリプランを使用して、クエリがSELECTステートメントであり、クエリの推定コストが低く、数レコードしか返されないことを確認します。このように、彼らは多くの害を及ぼすことはできません。また、実行されるすべてのクエリも監査します。

これは、私たちが提供するものの1つにすぎません。DevOpsサポートソリューションの詳細については、http：//www.Stackify.comをご覧ください。

はい。場合によっては、開発者を含むユーザーの一部のサブセットに、実稼働データのクエリへのある程度のアクセスを許可することは理にかなっています。ただし、2つの理由により、適切な制限を設定する必要があります。まず、DBAとして、すべてのユーザーが必要とするサービスのレベルを保証するために最善を尽くす必要があります。また、大量の削除やビジネスルールの違反など、意図しない不適切なクエリを防ぐ必要があります。言うまでもなく、適切なセキュリティ管理が必要です。

データベーステーブルへのアドホッククエリを直接許可しない理由が何であれ、ビューおよびストアドプロシージャへのクエリを許可する場合があります。データベースのアクセス許可を使用すると、テーブルに対するSELECTクエリを直接防ぐことができ、特定のユーザーがアクセスできるビューやストアドプロシージャを制限することもできます。この方法はユーザーベースに柔軟性を与えるだけでなく、正しく実装されたときにデータの整合性と実現可能性も保護します。

当社では、本番サービスに依存していない本番データベースの読み取り専用スレーブを維持しています。開発者は、実稼働データにアクセスするためのアクセス権を開発者に付与します。機密データ（顧客情報、支払い情報など）がある場合、これらのテーブルのレプリケーションを制限し、スレーブサーバーでサンプルデータテーブルを維持します。

いいえ。

これが開発/テスト/ UATサーバーがある理由です。実稼働環境からのデータをテスト環境にコピーして、開発者がテストを進めることができます。選択クエリは、実稼働環境の場合にも非常に有害です。負荷が増加し、ピーク時にパフォーマンス全体が低下する可能性があります。

必要な情報はすべて、DBA経由で送信する必要があります。DBAは、必要なことを実行（選択）して結果を送信できます。それが私たちの環境でのやり方です。

誰もが開発者が愚かで何も知らないと思っている理由がわかりません。さまざまな役割のサンプルを入手しましたが、それらは混乱しており、「実稼働中」であってはなりません。DBA、システム管理者、ネットワーク管理者、開発者など、すべてが混乱しています。

通常のネットワークログインがある環境では、誰も（dev、dba、sa）がサーバーまたはデータベースにアクセスできません。これらはすべて、使用する必要がある特定の「管理者」アカウントを持っています。はい、通常、dbaとsaはより頻繁に使用しますが、それらを軽く踏む必要があります。私はみんなに火傷しました。

したがって、良い日には、ITの役割はアクセスする必要がありません。しかし、シャットダウンはファンを襲い、すべての人がデッキを使い、問題を解決する適切な人が必要です。これは通常、アプリケーションを理解し、dbaとsaを特定のポイントに導く開発者によって導かれます。それは単に不必要な遅延または要求と承認です。

さらに、承認後に型監査が行われることは決してないため、承認は意味を持ちません。