本番環境での特権を削減するが、仕事を過度に困難にしないための指針

Windows 2008 R2でSQL Server 2005および2008を実行します。

開発者の本番環境での特権を削減します。私もDBAと同じように、本番環境への権限を制限し、必要に応じて昇格させたいと考えています。

私の主な目標は、愚かな過ちを排除することです-DBA によって行われるため、開発者はせいぜい本番環境で読み取りアクセスしかできません。私たちは間違いを犯さないスーパーヒーローであるように行動するのが好きですが、常に制作権を持っているわけではないのは理にかなっており、一部の人が推奨するベストプラクティスです。

最善のアプローチは何ですか？日常的に、およびインストール中に最も苦痛を感じないものは何ですか？

現在、すべてのサーバーとデータベースに対する権限を持つDBAのWindowsグループがあります。

OSやリモートログインの権限を下げることにも興味がありますが、DBの権限に最も関心があります。

古いトレースのSA権限を削除する前に、saとしてトレースを実行し、場合によっては所有権をクリーンアップするために、昇格された特権が必要になると思います。他にどのような問題が予想されますか？

あなたのアドバイスとあなたの経験を共有してくれてありがとう！

理想的には、運用中の運用データベースでは、開発者がサーバーまたはサーバー上のデータベースにアクセスできないようにする必要があります。このようなことは、SOXコンプライアンスのために最初に行う必要があることの1つです。

userIDが実行される種類の権限について、それらが本当に持つべき唯一の権限はdb_datareader、db_datawriter明示的ですGRANT EXECUTE ON x TO y（xuserIDの各ストアドプロシージャおよびユーザー定義関数に対してy）。

本番環境でトレースを実行する必要がある場合、いくつかの問題が発生し、すべてを説明するために万里の長城™が必要になります。最初の推奨事項は、本番環境と同じようにロックダウンされたQA環境を用意し、トレースを実行する必要がある場合は、prod dbのバックアップをQAに復元して、そこでトレースを実行することです。ここでも、SOX、HIPAA、またはPCI-DSSの要件がある場合は、QAに復元する前に製品データをより適切にサニタイズします。

現在、すべてのサーバーとデータベースに対する権限を持つDBAのWindowsグループがあります。

ログオンとデータの表示権限を付与します。ただし、DBAlyの職務を実行するには、昇格した特権で別のログインを使用します。私はこれを行う金融顧客を1人知っています。通常のWindows認証ベースのログインは、不注意で与える可能性のある損傷が制限されていました。DMLを復元して実行するには、別のSQL認証ログインで実行する必要があります。

私が使用した1つの政府機関は、サーバー/データベース管理者ごとに2つの別々のログインを使用していました。したがって、Tangurena私のドメインログイン（このログインは通常のUser特権を持つ）のTangurenaAdmin場合、私の個別のAdministratorログインになります。あなたが管理者を使用する場合は、すべての時間を占めてトラブルに巻き込まれるが、それは他のものへのアクセス権を持たない（無電子メールのような。ああ、あなたが言うことは悪いことであるように...という）。

私が取り組んでいる現在の政府機関には、各サーバー/ db管理者の権限が標準ユーザーよりも高くなっていますが、完全な管理者ではありません（PowerUserグループと考えてください）。ドメイン管理機能は、共有ドメイン管理アカウントで実行されます。

一般的なエラーは、間違ったデータベースの復元（本番サーバーで復元されたQAなど）であり、これは制限された権限または複数のログインによって解決されません。潜在的に破壊的なことをペアで行うことは、リスクを最小限に抑える1つの方法です。

saとしてトレースを実行するには、昇格された特権が必要になると思います

いいえ。ALTERTRACE権限のみが必要です。http：
//msdn.microsoft.com/en-us/library/ms187611.aspx

最初は、アクセスがしばらく削除されても問題のない開発環境またはQA環境ですべての特権プレイを行うことをお勧めします。アプリケーションにセキュリティの問題がないかどうかを確認する必要があります。

私たちの内部アプローチについてお話しします。

• すべてのアプリケーションは、データベース（通常はdb_ownerデータベースロール）に必要な権限を付与された単一のドメインユーザーを使用します。

• 時折のデータ読み取りには、SQLログインを使用します。そのユーザーには、データベースロール-db_datareaderを割り当てます。これは、メインデータベースクラスターでの開発者のアクセスを終了する場所です。他のアイデアについては、真夜中に行われるメインサーバーデータベースのコピー（ログ配布を使用して行われる）であるレポートサーバーデータベースを使用します。キラーアドホッククエリでレポートサーバーを強制終了しないために、メモリとCPUのリソースグループ割り当てを使用します。

• DBAチームの場合、マシンとサーバーに対するすべての特権を持つドメイングループがあります（Windowsマシンではadmin、sqlサーバーではsysadmin）。

• インストールの場合、更新を実行するときに使用するデータベースのdb_ownerであるSQLユーザーがいます。DDLトリガーを使用してスキーマの変更を監視し、インストール中に行われた変更または個別の変更としてどの変更が行われたかを確認します。

• 経験豊富な開発者には時々例外がいくつかありますが、彼らのニーズが満たされた後、私たちは彼らのアクセスを削除します-彼らは彼らのドメインログインに基づいて権限を受け取ります。

ログインとユーザーを操作するすべての方法については、Management Studioのサーバーセキュリティフォルダーで、必要なすべてのログインを作成し、それらをデータベースに関連付けて、必要なロールを付与します。アクションをスクリプト化すると、最初にサーバーログインが作成され、次にそのログインに接続されたデータベースユーザーが作成され、そのユーザーにデータベースロールが割り当てられます。スクリプトをスクリプトセットに保持できるため、どのユーザーがライブでキックしているのか、そうでないのかを毎回確認できます。

SQLサーバーでは、データベースユーザーを作成し、database role読み取り/書き込み/所有権のアクセス許可を割り当てます。ユーザーが本番環境に移行されたら、移行されたデータベースユーザーに移動して、必要のない役割のチェックを外します。たとえば、ユーザーstanがテスト中のdb_owner（データベースの所有権）のメンバーであるとします。ユーザーstanを本番環境に移行したら、それをdb_ownerから取り出し、db_datareader（読み取り専用）の役割のみを割り当てることができます。

SQL 2005以降では、を使用してより詳細な制御を行うことができますschema。詳細については、スキーマのこのリンクを確認してください。