今日の組織は、膨大な量の機密データを収集し生成しています。その多くは SQL Server データベースに保存されているため、SQL Server security の管理は、重要なアプリケーションやサービスを保護するうえで極めて重要です。強力な Microsoft SQL Server セキュリティ対策を導入することで、組織はサイバー脅威から防御し、GDPR、HIPAA、PCI DSS などの規制に準拠できます。本ガイドでは、認証、認可、暗号化、監査に加えて、SQL Server を安全に保つためのベストプラクティスなど、SQL Server セキュリティの基本を解説します。GDPR, HIPAA, and PCI DSS. This guide covers SQL Server security basics, including authentication, authorization, encryption, auditing, and best practices for securing SQL Server.
本ガイドは、SQL Server セキュリティを強化するための確かな基盤を提供します。プラットフォームおよびネットワークのセキュリティ、認証と認可、データの暗号化、監査、アプリケーションのセキュリティなど、理解すべき重要な領域をすべて取り上げます。さらに、脅威の状況が進化していく中で SQL Server データベースを安全に保つために、常に把握しておきたい主要トレンドも探ります。
厳選した関連コンテンツ:
SQL Server セキュリティの基礎
SQL Server セキュリティの脅威を理解する
攻撃者は、弱いパスワード のような MS SQL Server のセキュリティ上の脆弱性や、設定ミスのある権限を悪用します。攻撃者は、より深いアクセスを得るために権限を昇格し、SQL Server の データベースのセキュリティ を脅かす可能性があります。SQLインジェクション攻撃は引き続き主要な懸念であり、不正アクセス、データの改ざん、または削除を可能にします。
もう一つの代表的な攻撃ベクトルが SQL インジェクション攻撃です。実際、SQL インジェクションは Web アプリケーションに対する最も重大なセキュリティリスクの一つに位置付けられています。この手法は、アプリケーションのクエリに悪意のある SQL コードを注入するものであり、悪意のある攻撃者が重要なデータにアクセスしたり、変更または削除したりできるようにします。
SQL Server セキュリティ フレームワーク
SQL Server のセキュリティ管理を徹底するために、Microsoft は階層化されたセキュリティ モデルに従います:
- Securables(保護対象): 保護が必要なテーブル、ビュー、ストアド プロシージャなどのデータベース オブジェクト。
- Principals(主体): アクセスを要求するエンティティ(ユーザー、ログイン、アプリケーション)。
- 権限: サーバー レベル、データベース レベル、およびオブジェクト レベルでロールベースのアクセス制御(RBAC)により管理され、Securables に対して許可される操作を定義します。
プリンシパルが securables にアクセスできる能力は、さまざまな種類の権限によって管理されます。:
- securable に割り当てられた権限は、SELECT、INSERT、または EXECUTE のように、その securable に対して実行できる操作を定義します。
- プリンシパルに付与された権限によって、そのプリンシパルがアクセスできる securables と、実行できる操作が制限されます。権限をプリンシパルに直接割り当てるのではなく、ロールベースのアクセス制御(RBAC)を使って割り当てるのがベストプラクティスです。RBAC については、この文章の後半でさらに詳しく説明します。
権限は階層モデルを使用して継承できます。サーバーレベル > データベースレベル > オブジェクトレベル。これにより、データベースシステムのさまざまな部分へのアクセスをきめ細かく制御できます。
変更追跡とコンプライアンスのための SQL Server 監査
詳しく見るプラットフォームおよびネットワーク セキュリティ
攻撃対象領域(attack surface area)を減らすことは、SQL Server を保護するうえで不可欠です。ベスト プラクティスには次が含まれます:
- SQL Server の監査 ポリシーを適用して、不正なアクセス試行を監視します。
- 使用していないサービス、サンプル データベース、デフォルト アカウントを無効にします。
- 行レベルのセキュリティ(row-level security)と最小特権の原則を用いて、サーバー レベルのアクセスを制限します。
- 機密情報を隠すためにデータマスキング手法を徹底します。
物理的セキュリティのベストプラクティス
セキュリティは物理的な防護から始まります。すべての SQL Server は、キーカード、PIN、または生体認証などの認証メカニズムによってアクセスが保護されたデータセンターに設置する必要があります。そのエリアはカメラで監視し、サーバールームへのすべてのアクセスはログに記録してください。
オンサイトの SQL Server バックアップは、施錠でき、防火・防水仕様の保管キャビネットに保管する必要があります。さらに、追加のコピーは、アクセス制御された別の施設でのオフサイト保管、または信頼できるクラウドストレージに保管してください。
オペレーティングシステムおよびネットワークの保護
SQL Server の攻撃対象領域をさらに減らすには、自動更新を有効にし、パッチを速やかに適用してください。内部ファイアウォールを構成して、必要なポートのみ(例:TCP 1433)を許可するようにし、重要なサーバーをセグメント化します。加えて、次の点も必ず行ってください:
- 不要なサービスや使用していないネットワークプロトコルを無効化します。
- 本番環境で不要なサンプルデータベースやコンポーネントは削除します。
- 使用していないデフォルトアカウントやサービスは無効化または削除します
- SQL Server へのリモートアクセスを制限します。
- SQL Server Configuration Manager のようなツールを使用して、安全な設定になっていることを確認してください。
クラウドベースの SQL Server セキュリティ
オンプレミスのリソースを保護するセキュリティ対策は、クラウドに移行したリソースには必ずしもそのまま適用できません。Azure SQL や Amazon RDS のようなクラウドソリューションでは、専用の Microsoft SQL Server のセキュリティ対策が必要です。たとえば Azure Defender for SQL は、脆弱性評価や SQL Server の監査機能などのマネージドサービスを提供します。
- Azure Defender for SQL は、Azure クラウド環境で SQL データベースを保護するための包括的なセキュリティ ソリューションであり、高度な脅威防御と脆弱性評価を提供します。
- Amazon RDS は、AWS 上でホストされている SQL データベースを保護するために、ID およびアクセス管理(IAM)や自動バックアップ&スナップショットなどの堅牢なセキュリティ機能を提供します。
- Google Cloud SQL は、認証とアクセス制御、暗号化、ネットワークセキュリティなどを含め、SQL データベースを保護するための複数のセキュリティ機能を提供します。
認証と認可
認証モード
SQL Server を保護するには、データベース リソースにアクセスしようとするプリンシパルを効果的に認証することも必要です。SQL Server は次の認証オプションをサポートしています:
- Windows 認証 は推奨オプションです。SQL Server のセキュリティ管理では、Active Directory のポリシーを活用するため、これが好まれます。さらに、ユーザーを認証するために Active Directory (AD) を利用するため、AD の パスワード ポリシー やその他のセキュリティ コントロールを活用できます。
- SQL Server 認証データベース サーバーにユーザー名とパスワードを保存することで動作します。Active Directory が利用できない状況で使用できます。
- SQL Server をさらに保護するには、次の方法を使用して多要素認証(MFA)を導入してください:
- ワンタイム パスワード(OTP)
- 生体認証
- ハードウェア セキュリティ キー
- Contained Database Users は、SQL Server のログインに依存しないデータベース固有のユーザーです。代わりに、その認証情報はデータベース自体に保存されます。これにより移植性が向上し、サーバー間でデータベースを移行する際のユーザー管理も簡単になります。
Role-Based Access Management
先ほども述べたように、ベストプラクティスでは、ユーザーやアプリケーションに直接権限を割り当てるのではなく RBAC を使用することが推奨されています。RBAC を使用すると、正確性と透明性が向上する一方で、管理の手間(管理負荷)が大幅に削減されます。
RBAC では、権限はロールに付与され、ユーザーは割り当てられたロールから権限を継承します。あらかじめ定義された SQL Server のロールには、次のものが含まれます:
- Server roles は SQL Server インスタンス レベルで適用されます。ログインの管理、サーバー設定の構成、バックアップの実行などの管理タスクを委任するために使用されます。組み込みロールには、sysadmin、serveradmin、securityadmin が含まれます。
- データベースのロール 特定のデータベース内でアクセス許可を定義します。db_owner、db_datareader、db_datawriter などの事前定義済みロールは、職務の分離を支援し、過剰な権限を制限します。
- アプリケーションのロール は、個々のユーザーではなくアプリケーションに対して特定の権限を付与する特別なデータベースロールです。意図したアプリケーションを通じてのみデータへアクセスできるように制限することで、セキュリティが強化されます。
- 組織は、自社の具体的なニーズに合わせてカスタムロールを定義することもできます。
認証の強化
今日ではパスワードが非常に簡単に侵害されてしまうため、貴重なデータを守るのにパスワードだけに頼るべきではありません。多要素認証(Multifactor authentication, MFA)は、アクセスを許可する前に複数の形式の検証を要求することでセキュリティを強化します。選択肢には次のものがあります。
- SMS またはメールで送信されるワンタイムコード(OTP)
- 指紋や顔認識などのバイオメトリクス
- YubiKey や FIDO2 のようなハードウェアセキュリティキー
データの暗号化と保護
SQL Server における暗号化
組織は、機密データがいずれは何らかの形で公開されることを前提として運用しなければなりません。暗号化により、盗まれたデータが権限のない攻撃者にとって読み取れない状態に保たれるようにすることができます。
以下は SQL Server が提供する代表的な暗号化の一部です:
- Transparent Data Encryption (TDE) — データベース ファイルをリアルタイムに暗号化し、保存データを物理レベルで保護します。TDE は、SQL Server の master database に保存されているデータベース暗号化キー(DEK)を使用して、バックアップを含むデータベース全体を暗号化します。
- Always Encrypted — 信用カード情報や社会保障番号などの高度に機密性の高いデータを、アプリケーション層で暗号化することで保護することを目的としています。暗号化キーは SQL Server の外部に保存されるため、データベース管理者のような非常に特権のあるユーザーであっても機密情報を閲覧できません。
- Windows Data Protection API (DPAPI) — Windows ベースの暗号化機能を使用して、SQL Server の資格情報、キー、およびその他の機密情報を暗号化します。
Dynamic Data Masking (DDM)
暗号化はデータ全体を判読できない形式に変換し、復号にはキーが必要です。一方で DDM は、情報が権限のないユーザーに表示される際に機密データの一部を隠すことで、元のデータはそのまま保持します。たとえば、DDM により、社会保障番号、クレジットカードの詳細、電子メールアドレスをリアルタイムでマスクできます。
Column-Level Encryption (CLE)
DDM と同様に CLE も、対象を絞ったデータ保護を提供します。ただし、選択したデータをマスクするのではなく、データベースのテーブル内の特定の列を暗号化して行います。その結果、DDM は CLE よりもパフォーマンスへの影響が小さくなります。
Row-Level Security (RLS)
行レベル セキュリティは、ユーザーの身元またはロールに基づいて、データベース テーブル内の特定の行へのアクセスを制御します。これは、行をフィルターするためにテーブルに適用されるセキュリティ ポリシーを使用します。このフィルタリングは、セキュリティ述語(predicate)によって制御されます。セキュリティ述語とは、クエリを実行するユーザーに対して、その行が表示可能か、または変更可能かを判断する関数です。種類は2つあります。読み取り操作向けのフィルター述語と、書き込み操作向けのブロック述語です。
監査と監視
データベースのアクティビティを追跡し分析することは、脅威を検知し、規制上の要件への準拠を確実にするうえで非常に重要です。SQL Server Audit は、データベースに対して行われたアクティビティや変更を追跡するための組み込みフレームワークを提供します。
SQL Server Audit の機能
SQL Server Audit は、次の 2 つの主要な監査レベルをサポートしています。
- サーバーレベルの監査 は、SQL Server インスタンス全体にわたるイベント(ログイン、構成の変更、権限の変更、失敗した認証試行など)を記録します。その結果、 privilege escalation のような脅威の検出に役立ちます。
- データベースレベルの監査 は、特定のデータベース内で行われる操作(データの変更、スキーマの変更、権限の付与など)に焦点を当てます。
SQL Server で監査を設定するには、管理者が監査ポリシーを定義し、記録すべき操作やイベントを指定します。構成済みの監査は定期的に見直し、過剰なデータ保存を防ぐためにログ保持ポリシーを導入する必要があります。
セキュリティ ツールとユーティリティ
SQL Server Management Studio (SSMS) には組み込みの Vulnerability Assessment ツールが含まれており、古いパッチ、過剰な権限、古いプロトコルなどのセキュリティ上の弱点の把握に役立ちます。さらに、修復に向けた実行可能な推奨事項も提供できます。
SQL Server Data Discovery & Classification は、データベース内の潜在的に機密性の高いデータを自動的に検出し、個人を特定できる情報(PII)や金融記録などの適切な分類ラベルを推奨します。さらに、コンプライアンスおよび監査の目的で詳細なレポートを生成することもできます。
ほかにも、内蔵のセキュリティツールとして Security Catalog Views および Functions があり、次のような機能を提供します:
- データベースのセキュリティ設定および構成に関する包括的な可視化
- ユーザー権限およびアクセス制御メカニズムに関する詳細な洞察
- セキュリティ関連メタデータをリアルタイムで監視する機能
これらのツールは、管理者が特権昇格の試み、不正なユーザーアカウントの作成、誤設定されたセキュリティ設定を検出するのに役立ちます。
監視ツールの使用
SQL 環境を定期的に監視することは、不審なアクティビティを検出し、セキュリティ対策の有効性を評価するうえで非常に重要です。次のベストプラクティスにより、監視の取り組みを最大限に活かすことができます。
- ピーク時とオフピーク時の通常のパフォーマンス水準を測定します。
- それらの基準値を使用して、脅威を示唆し得る逸脱を特定し、セキュリティチームに通知するためのしきい値を設定します。
- 新たに発生している問題や最適化が必要な領域を示す可能性のあるパターンを探してください。
- 変化するビジネスニーズに合わせて、監視設定を定期的に更新してください。
セキュリティをさらに強化するために、従来の監視ツールに加えて、以下を補完してください。
- データアクセスコントローラー。これは、不正アクセスのリスクを最小化し、特権の昇格を防ぐのに役立ちます
- セキュリティ分析ツール 。機械学習と行動分析を用いて、異常なクエリのパターンや過剰なデータアクセスなどの不審なユーザー活動を検出します
アプリケーション セキュリティ
安全なアプリケーション開発
先ほど述べたとおり、SQLインジェクションはWebアプリケーションに対する最大級の脅威の1つです。これらの攻撃に対抗するための方法をいくつか紹介します。
- パラメータ化されたクエリを使用して、SQLコードをユーザー入力から分離します。
- データベースの権限を付与する際は、 principle of least privilege を厳格に遵守してください。
- パラメーター化された入力を伴うストアドプロシージャを使用して、データベースクエリをカプセル化します。
- 悪意のある SQL コードが含まれるリスクを最小化するために、厳格な入力検証を実装します。たとえば、データ型の制限により数値フィールドは数値のみを受け付け、日付フィールドは有効な日付形式のみを受け付けるようにできます。ほかの検証方法としては、ホワイトリストによる検証や、入力長の制限があります。
エラーハンドリングと情報漏えい
エラーメッセージを設定する際は、適切なバランスを取る必要があります。つまり、トラブルシューティングを容易にするのに十分な情報を提供したい一方で、攻撃者が悪用の試みをさらに洗練させるのに役立つ可能性のある詳細は含めないようにします。良い戦略として、開発環境では詳細なエラーメッセージを実装し、本番環境では汎用的なメッセージを使用することが挙げられます。汎用的なメッセージには、社内チームが参照できるエラーコードを含めることで、ユーザーに機密性の高いシステム情報を表示する必要をなくせます。
クライアントサイドのアプリケーション(Web やモバイル アプリケーションなど)は、ユーザーが直接アクセスできるため、特に攻撃を受けやすくなります。これらのベストプラクティスは、セキュリティの向上に役立ちます:
- 転送中のデータを保護するために、常に HTTPS(TLS暗号化)を使用してください。
- 暗号化されたローカルストレージや安全なクッキーなど、クライアント側で機密データを保存する際は安全な方法を使用してください。
- セキュリティパッチに対応するため、クライアント側のフレームワークやライブラリを最新の状態に保ってください。
- JavaScript のコンソールログに詳細なエラーメッセージが出力されないように無効化してください。
- RBAC を使用して、アクセス権限の正確なプロビジョニングを確実に行えるようにしましょう。
アプリケーションレベルのロール
アプリケーションロールは、特定のアプリケーション内でユーザー権限を制御し、整理するための方法を提供します。管理を簡素化しながら、セキュリティとコンプライアンスを強化できます。
アプリケーションロールの一般的な例を示します:
- 管理者 — ユーザー、設定、および構成を管理するための完全なアクセス権があります。
- マネージャー — レポートを確認し、取引を承認できますが、システム設定は変更できません
- ユーザー — コンテンツを作成および編集できますが、レコードは削除できません
ロール、権限、およびロールの割り当ての変更を必ず追跡してください。加えて、定期的なアクセスレビューを実施し、ユーザーが割り当てられたロールをまだ必要としているかどうかを確認します。
SQL Server のセキュリティに関するベストプラクティス
定期的なセキュリティ監査
定期的な監査は、SQL Server 環境を安全に保つために欠かせません。監査すべき主な項目は次のとおりです:
- データベース スキーマの変更 — 不適切な変更により、セキュリティ リスクが発生したり、システムの不安定さにつながる可能性があります。
- サーバーおよびデータベースの設定 — 暗号化設定、認証モード、アクセス制御を必ず確認してください。
- ユーザー アカウント — 利用していない、または不要なユーザー アカウントを速やかに削除することで、セキュリティ上の露出を最小限に抑えられます。
- ログインの失敗試行 — ログインの失敗試行が頻繁に発生している場合、ブルート フォース攻撃の可能性があります。
コンプライアンスの維持
今日、多くの組織はさまざまな規制に対応しなければなりません。たとえば医療(HIPAA)、小売(PCI DSS)、金融(SOX)のように、特定の業界に特化したものもあります。ほかにも、GDPRのように適用範囲がはるかに広いものがあります。
貴社に適用される規制要件に監査(auditing)の実施内容が合致していることを確認し、監査の前に必要な書類をすべて事前に用意しておきましょう。
実践に基づく SQL Server セキュリティ
実例に基づくケーススタディ
サイバー犯罪者は、そこに保存されている価値あるデータがあるため、日常的に SQL Server を狙います。とりわけ脅威アクターは、TCP ポート 1433 が開いている SQL Server を見つけるため、インターネットを積極的にスキャンしています。この誤設定を利用して、未パッチの脆弱性を悪用したり、SQL インジェクション攻撃を仕掛けたり、ブルートフォース(総当たり)によって、サーバーおよびそのデータベースに特権アクセスできるアカウントの支配権を獲得したりできます。
さまざまな種類の脅威が存在するため、異なるレベルでのセキュリティ対策(security controls)を含む、デフェンス・イン・デプス(defense-in-depth)戦略を採用することが不可欠です。そうすれば、1つの層が侵害された場合でも、他の保護策が引き続き有効な状態を維持し、脅威を軽減できます。たとえば、主要なファイアウォールが侵害された場合でも、強力な認証、アクセス制御ポリシー、暗号化によってデータは保護されます。
セキュリティ評価ツール
SQL Server Management Studio (SSMS) は、SQL Server データベースを管理するための Microsoft の主要なグラフィカル インターフェイス ツールです。管理者は、次のことができます。
- ログイン、ロール、および権限を管理します。
- データベースを暗号化します。
- データの発見と分類を実行します。
- データベースをスキャンして潜在的な脆弱性を特定します。
セキュリティ評価プレイブック は、組織がデータベースのセキュリティを評価し、改善するのに役立ちます。たとえば Microsoft は、Azure SQL Database と SQL Managed Instance における一般的なセキュリティ要件に対応するための包括的なプレイブックを提供しています。組織は、自社の SQL Server 環境およびセキュリティ要件に合わせて、独自のセキュリティ評価プレイブックを作成できます。
インシデント対応と復旧
セキュリティ侵害が発生した場合、被害を最小限に抑えるためには迅速かつ断固とした行動が不可欠です。準備のために、組織は、定期的にリハーサル(訓練)し、見直し、修正する詳細なインシデント対応と復旧計画を作成する必要があります。
関連するすべてのチームを必ず関与させてください。たとえば、IT は調査および潜在的な法的手続きを支援するために、影響を受けたシステムのフォレンジックイメージとその他の証拠を取得する必要があります。シニアリーダーシップと PR(広報)は、従業員、顧客、投資家、その他のステークホルダーを含む、すべての影響を受ける対象に確実に届けるためのコミュニケーション計画を用意しておく必要があります。
バックアップからデータを復元することは、復旧プロセスの重要な一部です。定期的なバックアップ手順を確立するだけでなく、チームは、データの完全性を検証し、復元プロセスが想定どおりに機能することを確認するために、バックアップを日常的にテストする必要があります。復旧時間目標を明確に定義することで、復旧作業の成果を測定しやすくなります。
SQL Server セキュリティにおける今後のトレンド
セキュリティの専門家も脅威アクターも、目標を前進させるために新しい技術を引き続き積極的に活用していくでしょう。特に、攻撃者は人工知能や機械学習をますます悪用して、より高度な脅威を作り出すようになります。一方で、防御側も同じ技術を利用して、異常検知や予測型の脅威分析を強化していくはずです。
もう一つの重要なトレンドは、オンプレミスおよびクラウドベースの SQL Server インスタンスの両方を保護するための統一的なアプローチを提供する、クラウドネイティブのセキュリティプラットフォームの利用が増えていることです。最後に、量子コンピューターが現在の暗号化方式を破る可能性があることを背景に、耐量子(量子耐性)アルゴリズムの研究が加速しています。
Netwrix が支援できること
SQL Server 環境を安全に保つには、変更を監視し、アクセスを追跡し、適切な設定を維持する必要があります。SQL のセキュリティを向上させる Netwrix 製品の例を以下に示します:
- Netwrix Access Analyzer – このツールは、SQL Server およびその他の IT システム全体における変更とアクセス イベントを可視化し、潜在的なセキュリティ脅威の検出を支援します。
- Netwrix Auditor for SQL Server – このツールはデータベースのアクティビティ、失敗したログイン、権限の変更を監視するため、不審な挙動の特定が容易になり、コンプライアンスの確保にも役立ちます。
- Netwrix Change Tracker – この製品は SQL Server の構成変更をログに記録し、無許可の変更を防止し、セキュリティのベストプラクティスを維持するのに役立ちます。
結論
SQL Server を保護するには、絶え間ない警戒と適応が必要です。データベースのセキュリティを強化するには、段階的な防御戦略を実装し、システムを定期的に監査し、最新の脅威や対策について常に情報を把握することに注力してください。
そして、セキュリティは一度きりの作業ではなく、継続的なプロセスであることも忘れないでください。セキュリティブログ、専門的なトレーニング、Microsoft の公式ドキュメントなどのリソースを活用して、継続的にスキルと知識を高めましょう。セキュリティを最優先し、ベストプラクティスを取り入れることで、複雑さを増すデジタル環境の中でもリスクを大幅に減らし、重要なデータ資産を保護できます。
Netwrix Auditor for SQL Server
よくある質問
SQL Server をどのように保護できますか?
脅威や脆弱性から SQL Server 環境を適切に保護するには、複数の層からなる管理策とソリューションが連携して機能する「多層防御(defense-in-depth)」戦略が必要です。主な戦略には、サーバーの物理的なセキュリティを確保すること、定期的なパッチ適用などのベストプラクティスと「最小権限(least privilege)」を徹底してアクセスを制限することで攻撃対象領域(attack surface)を減らすこと、機密データを暗号化することなどが含まれます。
Microsoft SQL Server は安全ですか?
他のあらゆるデータベースシステムと同様に、SQL Server を保護するには適切な実装と運用(メンテナンス)が必要です。デフォルト設定では最適なセキュリティが得られない場合があるため、管理者は組織の具体的な要件に基づいてサーバーを慎重に構成する必要があります。セキュリティは、効果的なパッチ管理の導入や強力な パスワードポリシー と、堅牢な監視および監査を行うことにも左右されます。
SQL Server におけるデータベース セキュリティとは何ですか?
データベースのセキュリティとは、不正なデータアクセスや改ざんのような脅威からデータを守るために、プロセスと統制(コントロール)を実装することです。認証メカニズム、アクセス権の管理、保管中および転送中のデータの暗号化など、複数の層からなるセキュリティ機能が必要です。SQL Server では、機密情報を保護する動的データマスキング(dynamic data masking)や、データアクセスをきめ細かい粒度で制御する行レベルのセキュリティ(row-level security)などの高度な機能が提供されます。
SQL Server のデータベースが信頼できるかどうかは、どう確認すればよいですか?
TRUSTWORTHY データベースプロパティは、SQL Server インスタンスがそのデータベースとその内容を信頼しているかどうかを示します。既定ではこのプロパティは OFF に設定されていますが、ALTER DATABASE ステートメントを使用して有効化できます。これを ON に設定すると、EXECUTE AS を使用するデータベースモジュール(例:ストアドプロシージャや関数)は、サーバーレベルの権限など、データベース外部のリソースにアクセスすることが許可されます。
SQL Server のデータベースが信頼できるかどうかを判断するには、SQL Server Management Studio でこの設定を確認するか、T-SQL クエリを使用します。
SQL Server におけるセキュリティとは何ですか?
SQL Server のセキュリティは、データおよびデータベース リソースを保護するための多層(マルチレイヤー)システムです。ユーザーの身元を確認する認証、アクセス権限レベルを制御する認可、機密データを保護する暗号化、そしてアクティビティを監視する監査が含まれます。セキュリティ モデルの主要な要素には、プリンシパル(ユーザーやアプリケーションなど)、セキュラブル(データベース、テーブル、保存プロシージャなど)、ロール(sysadmin や db_owner など)があります。
高度なデータ保護のために、SQL Server には動的データ マスキング(dynamic data masking)や行レベル セキュリティ(row-level security)といった機能が含まれています。
データベースのセキュリティを確保するのに役立つ 5 つの重要な手順は何ですか?
データベースのセキュリティを確保するのに役立つ 5 つのベストプラクティスは次のとおりです。
- 不要なサービスを制限することで Windows Server を強化(harden)します。特に、SQL Server Browser Service を無効にしてください。
- 暗号化を使用して、保存データおよび転送中のデータを保護します。
- 最小権限の原則に従って、サービスアカウントの権限を厳格に制限します。
- 通常の活動に関する基準値を設定し、脅威を示唆し得る異常を監視します。
- クエリをサニタイズし、パラメータ化されたステートメントを使用して、SQLインジェクションから保護します。
SQL にはどのようなセキュリティ機構がありますか?
SQL Server は、データを保護し、アクセスを制御するためのさまざまなセキュリティメカニズムを提供します。例として、リアルタイムで機密データを保護する動的データマスキング、特定のデータへの条件付きアクセスのための行レベルのセキュリティ(RLS)および列レベルのセキュリティ(CLS)、保管中のデータを暗号化する Transparent Data Encryption(TDE) などがあります。
共有する
もっと詳しく
著者について
James Anderson
テクニカル・プロダクト・マネージャー
James Anderson は Netwrix Access Analyzer および Netwrix Change Tracker のテクニカル・プロダクト・マネージャーです。リード・データ・エンジニア(Lead Data Engineer)、データ・アーキテクト(Data Architect)、DBA などの役割を含め、ソフトウェアとデータ分野で 15 年以上の経験があります。