SQL Server のセキュリティのベスト プラクティス

  • [アーティクル]

適用対象:SQL ServerAzure SQL DatabaseAzure SQL Managed Instance

この記事では、SQL Server のセキュリティの実現に役立つベスト プラクティスとガイドラインについて説明します。 SQL Server のセキュリティ機能の包括的な説明については、「SQL Server の保護」をご覧ください。

特定の製品のセキュリティのベスト プラクティスについては、Azure SQL Database と SQL Managed Instance および Azure VM 上の SQL Server に関する記事をご覧ください。

概要

多層セキュリティ手法は、異なるセキュリティ スコープを対象とする複数のセキュリティ機能を使用することにより、多層防御ソリューションを提供します。 SQL Server 2016 で利用できるようになり、後続のリリースで強化されたセキュリティ機能は、セキュリティの脅威に対処し、適切にセキュリティ保護されたデータベース アプリケーションを提供するのに役立ちます。

Azure はいくつかの業界規制および標準に準拠しているため、ユーザーは仮想マシンで実行されている SQL Server を使用して、標準に準拠しているソリューションを構築できます。 Azure での法規制遵守に関する情報については、 Azure トラスト センターを参照してください。

列レベルの保護

多くの場合、SQL Server データベースには顧客、従業員、企業秘密、製品データ、医療、財務、その他の機密データに関するデータが格納されるので、組織は列レベルでデータを保護する必要があります。 通常、機密性の高い列には、ID/社会保障番号、携帯電話番号、名、姓、財務口座の ID、個人情報だとみなされるその他のデータが含まれます。

このセクションで説明する方法と機能により、最小限のオーバーヘッドで列レベルの保護レベルが上がり、アプリケーションのコードを大きく変更する必要はありませｎ。

Always Encrypted を使用して、保存データと転送中のデータを暗号化します。 暗号化されたデータは、アプリケーション クライアント レベルでクライアント ライブラリによってのみ暗号化解除されます。 可能な場合は、明確な暗号化よりランダム化された暗号化を使います。 保護されたエンクレーブが設定された Always Encrypted は、ランダム化された暗号化のシナリオで BETWEEN、IN、LIKE、DISTINCT、結合、その他などの比較操作のパフォーマンスを向上させることができます。

Always Encrypted を使用できない場合、動的データ マスク(DDM)を使用して列レベルでデータを難読化します。 動的データ マスク(DDM)は Always Encrypted と互換性がありません。 可能な限り、動的データ マスクよりも Always Encrypted を使用することをお勧めします。

テーブル、ビュー、またはテーブル値関数に対して、列レベルで GRANT アクセス許可を使うこともできます。 列に付与できるのは“SELECT“、“REFERENCES“、“UPDATE“のアクセス許可のみであることに注意してください。 - テーブル レベルの“DENY“は、列レベルの“GRANT“よりも優先されません。

行レベルの保護

行レベル セキュリティ(RLS)は、データベース テーブルの行へのアクセスを管理するため、ユーザー実行コンテキストを使用する機能を有効にします。 RLS を使うと、ユーザーは自分に関係のあるレコードのみを表示できます。 これにより、アプリケーションを大幅に変更する必要なしに、アプリケーションに "レコード レベル" のセキュリティが提供されます。

ビジネス ロジックは、RLS 機能のオンとオフを切り替えるセキュリティ ポリシーによって制御されるテーブル値関数内にカプセル化されます。 セキュリティ ポリシーは、RLS が操作対象とするテーブルにバインドされた“FILTER“と“BLOCK“述語も管理します。 呼び出しを行ったユーザーに返されるレコードを制限するには、行レベル セキュリティ (RLS) を使います。 アプリケーションのユーザーが同じ SQL Server ユーザー アカウントを共有する中間層アプリケーションを通してデータベースに接続するユーザーに対しては、SESSION_CONTEXT (T-SQL) を使用します。 パフォーマンスと管理性を最適にするには、行レベル セキュリティのベスト プラクティスに従ってください。

ヒント

組織のセキュリティ態勢を最大限に高めるには、行レベル セキュリティ (RLS) を Always Encrypted または動的データ マスク (DDM) と組み合わせて使います。

ファイル暗号化

Transparent Data Encryption (TDE) は、データベース ファイルに保存時の暗号化を提供することにより、ファイル レベルでデータを保護します。 Transparent Data Encryption(TDE)は、データベース ファイルを暗号化解除する適切な証明書がなければ、データベース ファイル、バックアップ ファイル、tempdb ファイルをアタッチしたり、読み取ったりできないようにします。 Transparent Data Encryption(TDE)を使用しないと、攻撃者が物理メディア(ドライブまたはバックアップ テープ)を入手し、データベースを復元またはアタッチして内容を読み取る可能性があります。 Transparent Data Encryption (TDE) は、SQL Server の他のすべてのセキュリティ機能と併用できます。 Transparent Data Encryption (TDE) では、データ ファイルとログ ファイルの I/O の暗号化と暗号化解除がリアルタイムで実行されます。 TDE の暗号化は、ユーザー データベースに格納されたデータベース暗号化キー(DEK)を使用します。 データベース暗号化キーは、master データベースのデータベース マスター キーによって保護される証明書を使用して保護することもできます。

TDE を使用して保存データ、バックアップ、tempdb を保護します。

監査とレポート

SQL Server を監査するには、サーバー レベルまたはデータベース レベルで監査ポリシーを作成します。 サーバー ポリシーは、サーバー上の既存と新規作成のすべてのデータベースに適用されます。 簡素化のため、サーバー レベルの監査を有効にし、データベース レベルの監査ですべてのデータベースのサーバー レベルのプロパティを継承できるようにします。

セキュリティ対策が適用されている機密データが含まれるテーブルと列を監査します。 テーブルまたは列がセキュリティ機能による保護を必要とするほど重要な場合は、監査の対象として十分に重要であると見なす必要があります。 機密情報が含まれていても、アプリケーションやアーキテクチャによる何かの制限によって必要なセキュリティ対策を適用できないテーブルに対し、監査を実施して定期的にレビューすることが特に重要です。

ID と認証

SQL Server は、2 つの認証モードをサポートしています。Windows 認証モードと "SQL Server と Windows 認証モード" (混合モード) です。

ログインはデータベース ユーザーとは異なります。 最初に、ログインまたは Windows グループを、別のデータベース ユーザーまたはロールにマップします。 次に、データベース オブジェクトにアクセスするためのアクセス許可を、ユーザー、サーバー ロール、またはデータベース ロールに付与します。

SQL Server では、次の種類のログインがサポートされています。

  • ローカル Windows ユーザー アカウントまたは Active Directory ドメイン アカウント - SQL Serverは、Windows ユーザー アカウントの認証を Windows に依存します。
  • Windows グループ - Windows グループにアクセス権を付与すると、そのグループのメンバーであるすべての Windows ユーザー ログインにアクセス権が付与されます。 グループからユーザーを削除すると、グループから付与されていた権限がユーザーから削除されます。 グループ メンバーシップが推奨される戦略です。
  • SQL Server ログイン - SQL Server は、master データベースにユーザー名とパスワードのハッシュを格納します。
  • 包含データベース ユーザーは、データベース レベルで SQL Server 接続の認証を行います。 包含データベースは、その他のデータベースとデータベースをホストする SQL Server(ならびに master データベース)のインスタンスから分離されたデータベースです。 SQL Server では、Windows 認証と SQL Server 認証の両方で包含データベース ユーザーがサポートされます。

次の推奨事項とベスト プラクティスは、ID と認証方法をセキュリティで保護するのに役立ちます。

  • 最小特権のロール ベース セキュリティ戦略を使って、セキュリティ管理を強化します。

    • Active Directory ユーザーは AD グループに配置するのが基本で、AD グループは SQL Server ロールに存在する必要があり、SQL Server ロールにはアプリケーションで必要な最小限のアクセス許可を付与する必要があります。

  • Azure では、ロールベースのアクセス制御(RBAC)を使用し、最小特権のセキュリティを使用する

  • 可能な限り SQL Server 認証ではなく Active Directory を選び、特に、アプリケーションまたはデータベースのレベルでセキュリティを格納するのではなく Active Directory を選びます。

    • ユーザーが会社を退職する場合、アカウントを簡単に無効にできます。
    • ユーザーがロールを変更したり、組織を離れたりするとき、グループからユーザーを簡単に削除することもできます。 グループ セキュリティはベスト プラクティスと見なされます。

  • コンピューター レベルのアクセス権を持つアカウント(RDP を使用してコンピューターにログインするアカウントを含む)に対しては、多要素認証を使用します。 単一要素のパスワードベースの認証は、資格情報が侵害されたり誤って提供されたりする危険がある弱い形式の認証であるので、これは資格情報の盗難や漏洩から保護するのに役立ちます。

  • 推測が容易ではなく、その他のアカウントや用途に使用されていない強力で複雑なパスワードが必要です。 パスワードを定期的に更新し、Active Directory ポリシーを適用します。

  • グループ管理サービス アカウント (gMSA) は、パスワードの自動管理、簡略化されたサービス プリンシパル名 (SPN) の管理、および他の管理者への管理の委任を提供します。

    • gMSA を使用すると、Windows オペレーティング システムでアカウントのパスワードが管理され、管理者がパスワードを管理することはなくなります。
    • gMSA は、サービスを再起動せずにアカウントのパスワードを自動的に更新します。
    • gMSA を使用すると、管理に関する攻撃面が減少し、職務の分離が向上します。

  • DBA の AD アカウントに付与する権限を最小限に抑えます。仮想マシンへのアクセスを制限する職務、オペレーティング システムにログインする機能、エラー ログと監査ログを変更する機能、およびアプリケーションや機能をインストールする機能の分離を検討します。

  • sysadmin ロールから DBA アカウントを削除し、sysadmin ロールのメンバーにするのではなく、DBA アカウントには CONTROL SERVER を付与します。 システム管理者の役割は“DENY“を適用しませんが、“CONTROL SERVER“は適用します。

データ系列とデータ整合性

経時的なデータ変更の履歴レコードを保持すると、データの偶発的な変更への対処に役立つ場合があります。 アプリケーション変更の監査に役立つ場合もあり、不審者が不正なデータ変更を行ったときにデータ要素を回復できます。

  • テンポラル テーブルを使用して一定期間のレコードのバージョンを保持し、レコードの寿命に及ぶデータを表示してアプリケーションのデータの履歴表示を提供します。
  • テンポラル テーブルを使用すると、現在のテーブルの任意の時点でのバージョンを提供できます。

セキュリティ評価ツールと評価

次の構成と評価ツールは、インスタンス レベルで SQL Server 環境のセキュリティにおける攻撃対象領域のセキュリティの対処、データ セキュリティの機会の特定、ベスト プラクティス評価を提供します。

  • 攻撃対象領域の構成 - 悪意のあるユーザーによって攻撃される可能性があるいくつかの機能を最小限に抑えるため、環境に必要な機能のみを有効にする必要があります。
  • SQL Server の脆弱性評価 (SSMS) - SQL 脆弱性評価は、SSMS v17.4 以降のツールであり、データベースの潜在的な脆弱性の検出、追跡、修復に役立ちます。 脆弱性評価は、データベースのセキュリティの向上に役立つツールであり、データベースごとにデータベース レベルで実行されます。
  • SQL データ検出と分類(SSMS) - DBA がサーバーとデータベースを管理しつつ、データベースに含まれるデータの機密性を認識しないことは一般的です。 「データ検出と分類」は、データの秘密度レベルの検出、分類、ラベル付け、レポートを行う機能を追加します。 データの検出と分類は、SSMS 17.5 以降でサポートされます。

SQL の一般的な脅威

SQL Server を危険にさらすいくつかの一般的な脅威について知っておくと役に立ちます。

  • SQL インジェクション - SQL インジェクションとは、実行のために SQL Server のインスタンスに渡される文字列に、悪意のあるコードが挿入される攻撃の種類です。
    • インジェクション プロセスは、テキスト文字列を終了し、新しいコマンドを追加することによって行われます。 挿入されたコマンドが実行される前に別の文字列が追加されている可能性があるため、攻撃者は挿入される文字列を“--“のコメントマークで終了させます。
    • SQL Server は、受信する構文が有効なクエリをすべて実行します。
  • サイドチャネル攻撃およびマルウェアとその他の脅威に注意してください。

SQL インジェクションのリスク

SQL インジェクションのリスクを最小限にするには、次の項目を検討してください。

  • SQL ステートメントを作成するすべての SQL プロセスで、インジェクションの脆弱性を確認します。
  • パラメーター化された方法で、動的に生成される SQL ステートメントを作成します。
  • 開発者とセキュリティ管理者は、“EXECUTE“、“EXEC“、“sp_executesql“を呼び出すすべてのコードを確認する必要があります。
  • 次の入力文字を許可しないでください。
    • ;: クエリの区切り記号
    • ': 文字データ文字列の区切り記号
    • --: 単一行コメントの区切り記号
    • /* ... */: コメントの区切り記号
    • xp_: xp_cmdshell など、カタログ拡張ストアド プロシージャ
      • SQL Server 環境で xp_cmdshell を使用することはお勧めしません。 “xp_cmdshell“によってリスクが発生する可能性があるため、代わりに SQLCLR を使用するか、その他の代替手段を探してください。
  • 常にユーザー入力を検証し、エラー出力が流出して攻撃者に公開されないようにします。

サイドチャネルのリスク

サイドチャネル攻撃のリスクを最小限にするには、次のことを考慮してください。

  • アプリケーションとオペレーティング システムの最新のパッチを適用します。
  • ハイブリッド ワークロードの場合は、オンプレミスのすべてのハードウェアのファームウェアに、最新のパッチが適用されるようにします。
  • Azure では、機密性の高いアプリケーションとワークロードについては、分離された仮想マシン、専用ホスト、DC シリーズや第 3 世代 AMD EPYC プロセッサを搭載した Virtual Machines などの機密コンピューティング仮想マシンを使用することにより、サイドチャネル攻撃から保護を強化できます。

インフラストラクチャの脅威

次の一般的なインフラストラクチャの脅威を考慮してください。

  • ブルート フォース アクセス - 攻撃者は複数のパスワードをさまざまなアカウントに対して使用して、正しいパスワードが見つかるまで認証を試行します。
  • パスワード クラッキング、パスワード スプレー - 攻撃者は、慎重に作成した 1 つのパスワードを、既知のユーザー アカウントすべてに対して試行します (多数のアカウントに対して 1 つのパスワード)。 最初のパスワード スプレーが失敗した場合は、別の慎重に作成したパスワードを使用してもう一度試しますが、通常は検出を回避するために試行の間に一定の時間待ちます。
  • ランサムウェア攻撃は、マルウェアを使ってデータとファイルを暗号化し、重要なコンテンツにアクセスできないようにする、一種の標的型攻撃です。 その後、攻撃者は、暗号化解除キーの交換時に、通常は暗号通貨の形式で、被害者から金銭をだまし取ろうとします。 ほとんどのランサムウェアの感染は、ランサムウェアのインストールを試みる添付ファイルを含むメール メッセージ、または Web ブラウザーや他のソフトウェアの脆弱性を使用してランサムウェアをインストールしようとする悪用キットをホストしている Web サイトから始まります。

パスワードのリスク

攻撃者に簡単にアカウント名やパスワードを推測されたくないので、パスワードが検出されるリスクを軽減する次の手順が役立ちます。

  • 「Administrator」という名前を持たない一意のローカル管理者アカウントを作成します。
  • すべてのアカウントに複雑で強力なパスワードを使用します。 強力なパスワードを作成する方法の詳細については、「強力なパスワードを作成する」を参照してください。
  • 既定で、Azure は SQL Server 仮想マシンのセットアップ中に Windows 認証を選択します。 そのため、 SA ログインは無効となり、パスワードはセットアップによって割り当てられます。 SA ログインを使用または有効にしないことをお勧めします。 SQL ログインが必要な場合、次の方法のいずれかを使用します。

    • sysadmin メンバーシップを持つ SQL アカウントを一意の名前で作成します。 プロビジョニング中に SQL 認証を有効にすると、ポータルからこの操作を行うことができます。

      ヒント

      プロビジョニング中に SQL 認証を有効にしない場合、認証モードを手動で[SQL Server と Windows 認証モード]に変更する必要があります。 詳細については、「サーバー認証モードの変更」を参照してください。

    • SA ログインを使用する必要がある場合は、プロビジョニング後にログインを有効にし、新しい強力なパスワードを割り当てます。

ランサムウェアのリスク

ランサムウェアのリスクを最小限にするには、次のことを考慮してください。

  • ランサムウェアから保護するための最善の戦略は、RDP と SSH の脆弱性に特に注意を払うことです。 さらに、次の推奨事項を検討してください。
    • ファイアウォールを使用してポートをロックダウンする
    • 最新のオペレーティング システムとアプリケーションのセキュリティ更新プログラムを適用する
    • グループ管理サービス アカウント (gMSA)を使用します
    • 仮想マシンへのアクセスを制限します
    • Just-in-time (JIT) アクセスと Azure Bastion を要求します
    • ローカル コンピューターに sysinternals や SSMS を含むツールをインストールしないようにすることで、外部からのアクセスに対するセキュリティを強化します
    • 不要な Windows 機能、役割、有効化サービスをインストールしない
    • さらに、定期的に完全バックアップをスケジュールし、データベースのコピーを削除できないように、一般的な管理者アカウントとは別にセキュリティで保護する必要があります。

関連するコンテンツ