DBAはデータの保護者であり、保護者になるには2つの側面があります。 1つ目は完全性です。これには、データベースの整合性のチェック、バックアップの作成、問題が発生した場合の、適切に設計された包括的なデータベース回復計画の作成などのタスクが含まれます。
2番目の側面はセキュリティです。許可されたユーザーのみがデータにアクセスでき、必要なデータのみにアクセスできるようにすることをお勧めします。
Web上でセキュリティ専用の多数のリソースを見つけることができます。しかし、いくつかの重要な事柄には適切な注意が欠けていると思います。この記事では、これらのオプションに焦点を当て、それらを認識して正しく処理することが重要である理由を示したいと思います。
SQLServerを危険にさらす使命
あなたがシークレットエージェントであるロールプレイングゲームを作りましょう。あなたがそれを受け入れる場合、あなたの使命は TargetDBから非常に重要なデータを盗むことです。 SQLServerによってホストされるデータベース。このデータを取得して削除する必要があります。
ログインを取得することは可能ですが、サーバーへのすべてのログインには、ターゲットデータベースとデータに対する明示的なDENIED権限があります。エージェントが提供できる唯一の情報は、ログインの作成時にセキュリティプロトコルによる検証のために生成された情報です。
ターゲットサーバーからのデータベース情報。
サーバーのアクセス許可：
データベースのアクセス許可：
すべてのまともなエージェントとして、宿題をして、あなたが何を扱っているかを確認しましょう。
ログインしてTargetDBに接続するだけでは不十分です。 、ログインとそのマップされたユーザーに対するすべてのアクセス許可が明示的に拒否されるため。別のデータベースからアクセスする必要があります。
施錠されたドア
データベース間のアクションは簡単なことではありません。 2つのロックが付いた閉じたドアと考えてください。ここでは技術的な詳細に焦点を当てませんが、EXECUTE AS MSDNの記事を使用したデータベースの偽装の拡張を参照できます（そうすることを強くお勧めします）。
最初のロックはオーセンティケーターの信頼です 、2番目はデータベースの信頼です。 。
最初のロックから始めましょう。オーセンティケーターを信頼するということは、別のデータベースBにアクセスするには、データベースAの所有者に AUTHENTICATE を（明示的または暗黙的に）付与する必要があることを意味します。 データベースBの権限。
ちょっと待って！データベースレベルのオーセンティケーターは、データベース自体の所有者です（ db_owner と混同しないでください） データベースの役割！）。
データベースの所有者を確認してください：
SA ではないサーバーごとに1つのアカウントを使用することで、かなり良い慣習に従っていますが 、このようにして、彼らはあなたのために最初のロックを親切に開いてくれました。
2番目のロックに焦点を当てましょう。
どういうわけか、 TRUSTWORTHYを使用してサーバー上にデータベースを作成する必要があります プロパティオン 。ここでのベストプラクティスは、TRUSTWORTHYデータベースプロパティをOFFに設定することです。 。
これは私たちが言うべき時です：もしあなたがすでにそのようなデータベースを持っているとしたら？
MSDBデータベースです。
2番目のロックが実行されます。ロックを解除する必要すらありませんでした。
db_ownerロールの重要性
今、あなたは一つの挑戦に対処しなければなりません。どういうわけか、 db_ownerを使用してMSDBデータベースにアクセスする必要があります 暗黙の偽装権限があるため、データベースの役割。
MSDBは通常、データベース管理者の焦点ではないため、この使命はもはや不可能ではありません。 db_ownerのユーザーを獲得したという理由だけで何ができるか見てみましょう MSDBデータベースでのデータベースの役割：
TargetDBに接続してみてください ：
これは予期されるエラーです。提供されたログインに適用されたセキュリティプロトコルを覚えておいてください。始めましょう。
TargetDBに接続してみてください ターゲットデータを選択するには：
できます！変更してから、アクションを確認しましょう。
それだけです。
ミッションは達成されました。
ご覧のとおり、私は特定のセキュリティデータベース構成の組み合わせに焦点を合わせました。それらはデータベースの所有者であり、 TRUSTWORTHY MSDBに特に注意を払うデータベースオプション。提示されたシナリオは、機密データが同じように危険にさらされる可能性があるシナリオにすぎません。考えられる別のシナリオを今すぐ確認しましょう。
データベース所有者+信頼できる
よく知られている問題であるデータベースの所有権から始めて、背景の詳細を確認しましょう。データベースの所有者はどのログイン詳細を使用する必要がありますか？多くの人がSA 適切な選択です。
Googleで簡単に検索したところ、次のような回答が見つかりました。
「これが私にとって懸念事項だったことを今まで覚えていません。レポートを煩わしく見たり、データベースを所有している場合はユーザーを削除できないことを除けば、サーバーの操作には影響しないと思います。 saを選択するだけです 一貫性のために。」
または
「SAや他のユーザーがデータベースを所有していることを心配する必要はないと思います。重要なのは、データベースで誰が「何」を実行しているかです。したがって、有効な権限を持つユーザーを作成することをお勧めします。簡単にするために、所有者をSAとして指定できます。」
現在の状況では、データベース所有者としてSAアカウントを使用するのが最悪の慣行です 。個人的には、このトピックに関連するすべてのブログとすべてのドキュメントでこれを強調する必要があると思います。
有効な権限のみを持つユーザーを作成する場合はそれで十分ですが、残念ながら、これは通常の動作方法ではありません。 「最悪の可能性がある」シナリオに備える必要があります。デフォルトのデータベース所有者がSAの場合、前の例で何ができるかを考えてみてください。 ！
2番目のオプションであるTRUSTWORTHYに進みましょう データベースオプション。状況は少し良くなりますが、それでも共通の問題があります。一般的に考えられているように、ここでのベストプラクティスは、「信頼できる」データベースプロパティをオフに設定することです。 。このオプションが悪い理由を確認しました 。
しかし、これがすべてではありません。このプロパティを確認するためにいくつかのスクリプトを見つけようとすると、おそらく次のようなスクリプトが見つかります。
SELECT name FROM sys.databases WHERE is_trustworthy_on = 1 AND name != 'msdb'sp_Blitz SQL Serverの状態をチェックするスクリプトは、データベースのデフォルト設定（デフォルト値0としてTRUSTWORTHYを含む）もチェックし、デフォルト以外の設定を持つすべてのデータベースを報告します。ただし、スクリプトはシステムデータベースをスキップします。
さらに、このトピックに焦点を当てたMSKBの記事があります。 SQLServerでTRUSTWORTHYデータベース設定を使用するためのガイドラインを参照してください。
この記事には、TRUSTWORTHYビットがオンになっていて、データベース所有者がsysadminサーバーの役割に属しているデータベースをリストしたコードサンプルがあります。
SELECT SUSER_SNAME(owner_sid) AS DBOWNER, d.name AS DATABASENAME
FROM sys.server_principals r
INNER JOIN sys.server_role_members m ON r.principal_id = m.role_principal_id
INNER JOIN sys.server_principals p ON
p.principal_id = m.member_principal_id
inner join sys.databases d on suser_sname(d.owner_sid) = p.name
WHERE is_trustworthy_on = 1 AND d.name NOT IN ('MSDB') and r.type = 'R' and r.name = N'sysadmin'
これらのスクリプトで一般的なものは何ですか？各スクリプトはMSDBを除外しますが、MS KBの記事に記載されているように、「ミッション」で見たばかりです。
注 ：デフォルトでは、MSDBデータベースのTRUSTWORTHY設定はONに設定されています。この設定をデフォルト値から変更すると、MSDBデータベースを使用するSQLServerコンポーネントによって予期しない動作が発生する可能性があります。
このセクションの主な焦点は、TRUSTWORTHYデータベースオプションでもデータベース所有者プロパティ自体でもないことを強調したいと思いますが、これら2つのオプションの組み合わせです。 MSDBデータベースのTRUSTWORTHY設定がデフォルトでONに設定されているため、私は主にMSDBに集中しました。
結論
それは今のところすべてです。 SQL Serverのセキュリティに関連する実際のシナリオを確認し、確認しました。また、データベースの所有者やTRUSTWORTHYデータベース設定などの重要なデータベースオプションについても確認しました。
これらのオプションは非常に重要であるため、特にそれらを組み合わせて説明する場合は、これらのオプションにスポットライトを当てたかっただけです。