Azure SQL Database と Azure SQL Managed Instance で一般的なセキュリティ要件を解決するためのプレイブックPlaybook for addressing common security requirements with Azure SQL Database and Azure SQL Managed Instance

適用対象: Azure SQL Database Azure SQL Managed Instance

この記事では、一般的なセキュリティ要件を解決する方法に関するベスト プラクティスを提供します。This article provides best practices on how to solve common security requirements. 一部の要件はすべての環境には適用されないため、どの機能を実装するかについて、ご自分のデータベースおよびセキュリティ チームにご相談ください。Not all requirements are applicable to all environments, and you should consult your database and security team on which features to implement.

一般的なセキュリティ要件の解決Solving common security requirements

このドキュメントでは、Azure SQL Database および Azure SQL Managed Instance を使用する新規または既存のアプリケーションの一般的なセキュリティ要件を解決する方法に関するガイダンスを提供します。This document provides guidance on how to solve common security requirements for new or existing applications using Azure SQL Database and Azure SQL Managed Instance. これは、高レベルのセキュリティ領域別に整理されています。It's organized by high-level security areas. 特定の脅威の対処については、「一般的なセキュリティ上の脅威と考えられる軽減策」セクションを参照してください。For addressing specific threats, refer to the Common security threats and potential mitigations section. 提示されているいくつかの推奨事項は、アプリケーションをオンプレミスから Azure に移行する際に適用できますが、このドキュメントでは移行シナリオには焦点を当てていません。Although some of the presented recommendations are applicable when migrating applications from on-premises to Azure, migration scenarios are not the focus of this document.

このガイドで扱っている Azure SQL Database デプロイのオファーAzure SQL Database deployment offers covered in this guide

このガイドで扱っていないデプロイのオファーDeployment offers not covered in this guide

  • Azure Synapse Analytics (旧称 SQL Data Warehouse)Azure Synapse Analytics (formerly SQL Data Warehouse)
  • Azure SQL VM (IaaS)Azure SQL VMs (IaaS)
  • SQL ServerSQL Server

対象ユーザーAudience

このガイドの対象読者は、Azure SQL Database をセキュリティで保護する方法に関する問題に直面しているユーザーです。The intended audiences for this guide are customers facing questions on how to secure Azure SQL Database. このベスト プラクティスの記事が役に立つロールとして、次が挙げられます (ただし、これらに限定されません)。The roles interested in this best practice article include, but not limited to:

  • セキュリティ アーキテクトSecurity Architects
  • セキュリティ マネージャーSecurity Managers
  • コンプライアンス責任者Compliance Officers
  • プライバシー責任者Privacy Officers
  • セキュリティ エンジニアSecurity Engineers

このガイドの使用法Using this guide

このドキュメントは、既存の Azure SQL Database セキュリティに関するドキュメントとの併用を意図しています。This document is intended as a companion to our existing Azure SQL Database security documentation.

特に明記されていない限り、各セクションに記載されているすべてのベスト プラクティスに従って、それぞれの目標や要件を達成することをお勧めします。Unless otherwise stated, we recommend you follow all best practices listed in each section to achieve the respective goal or requirement. 特定のセキュリティに関するコンプライアンス基準やベスト プラクティスを満たすために、該当する場合は必ず、要件または目標セクションに重要な規制コンプライアンス制御が一覧表示されています。To meet specific security compliance standards or best practices, important regulatory compliance controls are listed under the Requirements or Goals section wherever applicable. この記事で言及されているセキュリティ基準と規制は、次のとおりです。These are the security standards and regulations that are referenced in this paper:

こちらに記載されている推奨事項とベスト プラクティスは、継続的に更新予定です。We plan on continuing to update the recommendations and best practices listed here. このドキュメントに関してご意見または訂正事項などがございましたら、この記事の下部にあるフィードバックのリンクを利用してお寄せください。Provide input or any corrections for this document using the Feedback link at the bottom of this article.

認証Authentication

認証は、ユーザーが本人の主張どおりの人物であることを証明するプロセスです。Authentication is the process of proving the user is who they claim to be. Azure SQL Database と SQL Managed Instance では、次の 2 種類の認証がサポートされています。Azure SQL Database and SQL Managed Instance support two types of authentication:

  • SQL 認証SQL authentication
  • Azure Active Directory 認証Azure Active Directory authentication

注意

一部のツールとサードパーティ アプリケーションでは、Azure Active Directory 認証がサポートされない場合があります。Azure Active Directory authentication may not be supported for all tools and 3rd party applications.

ID の中央管理Central management for identities

ID の中央管理には、次のような利点があります。Central identity management offers the following benefits:

  • サーバー、データベース、マネージド インスタンス間でログインを重複させずに、グループ アカウントを管理してユーザーのアクセス許可を制御します。Manage group accounts and control user permissions without duplicating logins across servers, databases and managed instances.
  • 簡素化された柔軟なアクセス許可の管理。Simplified and flexible permission management.
  • 大規模なアプリケーションの管理。Management of applications at scale.

実装方法:How to implement:

  • Azure Active Directory (Azure AD) 認証を使用して、ID の集中管理を行います。Use Azure Active Directory (Azure AD) authentication for centralized identity management.

ベスト プラクティス:Best practices:

  • Azure AD テナントを作成し、人間のユーザーを表すユーザーを作成し、アプリ、サービス、自動化ツールを表すサービス プリンシパルを作成します。Create an Azure AD tenant and create users to represent human users and create service principals to represent apps, services, and automation tools. サービス プリンシパルは、Windows および Linux でのサービス アカウントに相当します。Service principals are equivalent to service accounts in Windows and Linux.

  • グループ割り当てを使用して Azure AD プリンシパルにリソースへのアクセス権を割り当てます。Azure AD グループを作成し、グループにアクセス権を付与し、個々のメンバーをグループに追加します。Assign access rights to resources to Azure AD principals via group assignment: Create Azure AD groups, grant access to groups, and add individual members to the groups. データベースに、Azure AD グループをマップする包含データベース ユーザーを作成します。In your database, create contained database users that map your Azure AD groups. データベース内のアクセス許可を割り当てるには、適切なアクセス許可があるデータベース ロールを、Azure AD グループに関連付けられているユーザーに付与します。To assign permissions inside the database, put the users that are associated with your Azure AD groups in database roles with the appropriate permissions.

    注意

    SQL Managed Instance では、マスター データベースの Azure AD プリンシパルにマップされるログインを作成することもできます。In SQL Managed Instance, you can also create logins that map to Azure AD principals in the master database. CREATE LOGIN (Transact-SQL)」を参照してください。See CREATE LOGIN (Transact-SQL).

  • Azure AD グループを使用するとアクセス許可の管理が簡素化され、グループ所有者とリソース所有者の両方が、グループへのメンバーの追加またはグループからのメンバーの削除を行うことができます。Using Azure AD groups simplifies permission management and both the group owner, and the resource owner can add/remove members to/from the group.

  • サーバーまたはマネージド インスタンスごとに Azure AD 管理者用の個別のグループを作成します。Create a separate group for Azure AD administrators for each server or managed instance.

  • Azure AD 監査アクティビティ レポートを使用して Azure AD グループ メンバーシップの変更を監視します。Monitor Azure AD group membership changes using Azure AD audit activity reports.

  • マネージド インスタンスの場合、Azure AD 管理者を作成するための別の手順が必要です。For a managed instance, a separate step is required to create an Azure AD admin.

注意

  • Azure AD 認証は Azure SQL 監査ログに記録されますが、Azure AD サインイン ログには記録されません。Azure AD authentication is recorded in Azure SQL audit logs, but not in Azure AD sign-in logs.
  • Azure で付与された RBAC アクセス許可は、Azure SQL Database または SQL Managed Instance のアクセス許可には適用されません。RBAC permissions granted in Azure do not apply to Azure SQL Database or SQL Managed Instance permissions. このようなアクセス許可は、既存の SQL アクセス許可を使用して手動で作成またはマップする必要があります。Such permissions must be created/mapped manually using existing SQL permissions.
  • クライアント側では、Azure AD 認証にはインターネットへのアクセス、またはユーザー定義ルート (UDR) 経由の仮想ネットワークへのアクセスが必要です。On the client-side, Azure AD authentication needs access to the internet or via User Defined Route (UDR) to a virtual network.
  • Azure AD アクセス トークンはクライアント側にキャッシュされ、その有効期間はトークンの構成によって異なります。The Azure AD access token is cached on the client side and its lifetime depends on token configuration. Azure Active Directory における構成可能なトークンの有効期間」という記事を参照してください。See the article, Configurable token lifetimes in Azure Active Directory
  • Azure AD Authentication の問題のトラブルシューティングのガイダンスについては、次のブログを参照してください。Azure AD のトラブルシューティングFor guidance on troubleshooting Azure AD Authentication issues, see the following blog: Troubleshooting Azure AD.

Azure Multi-Factor AuthenticationAzure Multi-Factor Authentication

次で言及されています: OSA プラクティス #2、ISO アクセス制御 (AC)Mentioned in: OSA Practice #2, ISO Access Control (AC)

Azure Multi-Factor Authentication は、複数の形式の認証を要求することにより、セキュリティを強化するのに役立ちます。Azure Multi-Factor Authentication helps provides additional security by requiring more than one form of authentication.

実装方法:How to implement:

  • 条件付きアクセスを使用して Azure AD で Multi-Factor Authentication を有効にし、対話型認証を使用します。Enable Multi-Factor Authentication in Azure AD using Conditional Access and use interactive authentication.

  • 別の方法として、Azure AD または AD ドメイン全体で Multi-Factor Authentication を有効にすることもできます。The alternative is to enable Multi-Factor Authentication for the entire Azure AD or AD domain.

ベスト プラクティス:Best practices:

ユーザーに対するパスワードベースの認証の使用を最小限にするMinimize the use of password-based authentication for users

次で言及されています: OSA プラクティス #4、ISO アクセス制御 (AC)Mentioned in: OSA Practice #4, ISO Access Control (AC)

パスワードベースの認証方法は、強度が低い認証形式です。Password-based authentication methods are a weaker form of authentication. 資格情報が侵害されたり、誤って漏洩したりする可能性があります。Credentials can be compromised or mistakenly given away.

実装方法:How to implement:

  • パスワードの使用を排除する Azure AD 統合認証を使用します。Use an Azure AD integrated authentication that eliminates the use of passwords.

ベスト プラクティス:Best practices:

  • Windows の資格情報を使用したシングル サインオン認証を使用します。Use single sign-on authentication using Windows credentials. オンプレミスの AD ドメインを Azure AD とフェデレーションし、(Azure AD を使用するドメインに参加しているコンピューターに対して) 統合 Windows 認証を使用します。Federate the on-premises AD domain with Azure AD and use Integrated Windows authentication (for domain-joined machines with Azure AD).

アプリケーションに対するパスワードベースの認証の使用を最小限にするMinimize the use of password-based authentication for applications

次で言及されています: OSA プラクティス #4、ISO アクセス制御 (AC)Mentioned in: OSA Practice #4, ISO Access Control (AC)

実装方法:How to implement:

  • Azure マネージド ID を有効にします。Enable Azure Managed Identity. また、統合認証や証明書ベースの認証を使用することもできます。You can also use integrated or certificate-based authentication.

ベスト プラクティス:Best practices:

パスワードとシークレットを保護するProtect passwords and secrets

パスワードの使用を避けられない場合は、それらがセキュリティで保護されていることを確認します。For cases when passwords aren't avoidable, make sure they're secured.

実装方法:How to implement:

  • Azure Key Vault を使用してパスワードとシークレットを格納します。Use Azure Key Vault to store passwords and secrets. 適用できる場合は必ず、Azure AD ユーザーを含む Azure SQL Database に対して Multi-Factor Authentication を使用します。Whenever applicable, use Multi-Factor Authentication for Azure SQL Database with Azure AD users.

ベスト プラクティス:Best practices:

  • パスワードやシークレットを回避できない場合は、ユーザー パスワードとアプリケーション シークレットを Azure Key Vault に保存し、Key Vault のアクセス ポリシーを使用してアクセスを管理します。If avoiding passwords or secrets aren't possible, store user passwords and application secrets in Azure Key Vault and manage access through Key Vault access policies.

  • アプリ開発フレームワークによっては、アプリ内のシークレットを保護するための、フレームワーク固有のメカニズムが提供されている場合もあります。Various app development frameworks may also offer framework-specific mechanisms for protecting secrets in the app. 次に例を示します。ASP.NET Core アプリFor example: ASP.NET core app.

レガシ アプリケーションに対して SQL 認証を使用するUse SQL authentication for legacy applications

SQL 認証とは、ユーザーがユーザー名とパスワードを使用して Azure SQL Database または SQL Managed Instance に接続するときに、そのユーザーを認証することを指します。SQL authentication refers to the authentication of a user when connecting to Azure SQL Database or SQL Managed Instance using username and password. ログインは、サーバーまたはマネージド インスタンスごとに作成し、ユーザーはデータベースごとに作成する必要があります。A login will need to be created in each server or managed instance, and a user created in each database.

実装方法:How to implement:

  • SQL 認証を使用します。Use SQL authentication.

ベスト プラクティス:Best practices:

アクセス管理Access management

アクセス管理 (承認とも呼ばれます) とは、承認されたユーザーの Azure SQL Database または SQL Managed Instance へのアクセス権と特権を制御および管理するプロセスです。Access management (also called Authorization) is the process of controlling and managing authorized users' access and privileges to Azure SQL Database or SQL Managed Instance.

最小特権の原則を実装するImplement principle of least privilege

次で言及されています: FedRamp コントロール AC-06、NIST:AC-6、OSA プラクティス #3Mentioned in: FedRamp controls AC-06, NIST: AC-6, OSA Practice #3

最小特権の原則には、ユーザーは自分のタスクを完了するのに必要である以上の特権を持つべきではないと記載されています。The principle of least privilege states that users shouldn't have more privileges than needed to complete their tasks. 詳細については、「Just Enough Administration」という記事を参照してください。For more information, see the article Just enough administration.

実装方法:How to implement:

必要なタスクを完了するのに必要なアクセス許可のみを割り当てます。Assign only the necessary permissions to complete the required tasks:

  • SQL データベースの場合:In SQL Databases:

    • 粒度の細かいアクセス許可とユーザー定義データベース ロール (Managed Instance ではサーバー ロール) を使用します。Use granular permissions and user-defined database roles (or server-roles in Managed Instance):
      1. 必要なロールを作成しますCreate the required roles
      2. 必要なユーザーを作成しますCreate required users
      3. ユーザーをメンバーとしてロールに追加しますAdd users as members to roles
      4. 次に、アクセス許可をロールに割り当てます。Then assign permissions to roles.
    • 不要なロールにユーザーを割り当てないようにしてください。Make sure to not assign users to unnecessary roles.
  • Azure Resource Manager の場合:In Azure Resource Manager:

ベスト プラクティス:Best practices:

次のベスト プラクティスは省略可能ですが、セキュリティ戦略の管理容易性とサポート容易性が向上します。The following best practices are optional but will result in better manageability and supportability of your security strategy:

  • 可能ならば、最も可能性の低いアクセス許可セットから開始し、真の必要性 (および正当性) がある場合に 1 つずつアクセス許可の追加を開始します。これは、アクセス許可を 1 つずつ除去していくという反対のアプローチとは逆になります。If possible, start with the least possible set of permissions and start adding permissions one by one if there's a real necessity (and justification) – as opposed to the opposite approach: taking permissions away step by step.

  • 個々のユーザーにアクセス許可を割り当てないようにします。Refrain from assigning permissions to individual users. 代わりに、一貫してロール (データベースまたはサーバーのロール) を使用します。Use roles (database or server roles) consistently instead. ロールは、アクセス許可のレポートとトラブルシューティングに非常に役立ちます。Roles helps greatly with reporting and troubleshooting permissions. (Azure RBAC では、ロールによるアクセス許可の割り当てのみがサポートされます)。(Azure RBAC only supports permission assignment via roles.)

  • 正確に必要な分だけのアクセス許可を備えたカスタム ロールを作成して使用します。Create and use custom roles with the exact permissions needed. 実際に使用される一般的なロールは次のとおりです。Typical roles that are used in practice:

    • セキュリティ展開Security deployment
    • 管理者Administrator
    • DeveloperDeveloper
    • サポート担当者Support personnel
    • 監査担当者Auditor
    • 自動プロセスAutomated processes
    • エンド ユーザーEnd user
  • ロールのアクセス許可がユーザーに必要なアクセス許可と完全に一致する場合にのみ、組み込みロールを使用します。Use built-in roles only when the permissions of the roles match exactly the needed permissions for the user. ユーザーは複数のロールに割り当てることができます。You can assign users to multiple roles.

  • データベース エンジンのアクセス許可は、次のスコープ内で適用できることを覚えておいてください (スコープが小さいほど、付与されるアクセス許可の影響も小さくなります)。Remember that permissions in the database engine can be applied within the following scopes (the smaller the scope, the smaller the impact of the granted permissions):

    • Azure のサーバー (マスター データベースの特別なロール)Server (special roles in master database) in Azure
    • データベースDatabase
    • スキーマSchema
    • オブジェクト (テーブル、ビュー、プロシージャなど)Object (table, view, procedure, etc.)

    注意

    オブジェクト レベルでアクセス許可を適用することは推奨されません。このレベルでは、不必要な複雑さが実装全体に追加されるからです。It is not recommended to apply permissions on the object level because this level adds unnecessary complexity to the overall implementation. オブジェクト レベルのアクセス許可を使用する場合は、それらを明確に文書化する必要があります。If you decide to use object-level permissions, those should be clearly documented. 列レベルのアクセス許可も同様です。それらは、同じ理由により、さらにお勧めできません。The same applies to column-level-permissions, which are even less recommendable for the same reasons. また、既定ではテーブルレベルの拒否によって列レベルの許可がオーバーライドされないことにも注意してください。Also be aware that by default a table-level DENY does not override a column-level GRANT. このため、情報セキュリティ国際評価基準に準拠したサーバー構成をアクティブにする必要があります。This would require the common criteria compliance Server Configuration to be activated.

  • 脆弱性評価 (VA) を使用して通常のチェックを実行し、アクセス許可が多すぎるかどうかをテストします。Perform regular checks using Vulnerability Assessment (VA) to test for too many permissions.

職務の分離を実装するImplement Separation of Duties

次で言及されています: FedRamp:AC-04、NIST:AC-5、ISO:6.1.2、PCI 6.4.2、SOC:CM-3、SDL-3Mentioned in: FedRamp: AC-04, NIST: AC-5, ISO: A.6.1.2, PCI 6.4.2, SOC: CM-3, SDL-3

職務の分離では、機密性の高いタスクを、別々のユーザーに割り当てられる複数のタスクに分割する必要性が述べられています。Separation of Duties, also called Segregation of Duties describes the requirement to split sensitive tasks into multiple tasks that are assigned to different users. 職務を分離することで、データの侵害を防ぐことができます。Separation of Duties helps prevent data breaches.

実装方法:How to implement:

  • 必要な職務の分離レベルを特定します。Identify the required level of Separation of Duties. 例 :Examples:

    • 開発/テスト環境と運用環境の間Between Development/Test and Production environments
    • セキュリティ上機密性の高いタスクと、データベース管理者 (DBA) の管理レベル タスクと、開発者のタスク。Security-wise sensitive tasks vs Database Administrator (DBA) management level tasks vs developer tasks.
      • 例 :監査者、ロール レベル セキュリティ (RLS) のセキュリティ ポリシーの作成、DDL アクセス許可を持つ SQL Database オブジェクトの実装。Examples: Auditor, creation of security policy for Role-level Security (RLS), Implementing SQL Database objects with DDL-permissions.
  • システムにアクセスするユーザーの包括的階層 (および自動化されたプロセス) を特定します。Identify a comprehensive hierarchy of users (and automated processes) that access the system.

  • 必要なユーザー グループにしたがってロールを作成し、ロールにアクセス許可を割り当てます。Create roles according to the needed user-groups and assign permissions to roles.

    • Azure portal での、または PowerShell 自動化を使用した管理レベルのタスクには、Azure ロールを使用します。For management-level tasks in Azure portal or via PowerShell-automation use Azure roles. 要件に一致する組み込みロールを見つけるか、使用可能なアクセス許可を使用して Azure カスタム ロールを作成します。Either find a built-in role matching the requirement, or create an Azure custom role using the available permissions
    • サーバー全体のタスク (新しいログイン、データベースの作成) のサーバー ロールをマネージド インスタンスに作成します。Create Server roles for server-wide tasks (creating new logins, databases) in a managed instance.
    • データベース レベルのタスクに対するデータベース ロールを作成します。Create Database Roles for database-level tasks.
  • 特定の機密性の高いタスクについては、ユーザーに代わってタスクを実行するために、証明書によって署名された特殊なストアド プロシージャを作成することを検討してください。For certain sensitive tasks, consider creating special stored procedures signed by a certificate to execute the tasks on behalf of the users. デジタル署名されたストアド プロシージャの重要な利点の 1 つは、プロシージャが変更された場合に、以前のバージョンのプロシージャに与えられたアクセス許可が直ちに削除されることです。One important advantage of digitally signed stored procedures is that if the procedure is changed, the permissions that were granted to the previous version of the procedure are immediately removed.

  • Azure Key Vault のカスタマー マネージド キーを使用して Transparent Data Encryption (TDE) を実装し、データ所有者とセキュリティ所有者の間での職務の分離を可能にします。Implement Transparent Data Encryption (TDE) with customer-managed keys in Azure Key Vault to enable Separation of Duties between data owner and security owner.

  • 非常に機密性が高いと見なされるデータを DBA が表示できないようにしながらも、DBA のタスクを実行できるようにするには、ロール分離と共に Always Encrypted を使用することができます。To ensure that a DBA can't see data that is considered highly sensitive and can still do DBA tasks, you can use Always Encrypted with role separation.

  • Always Encrypted の使用が不可能な場合や、少なくとも大きなコストと努力を払わなくては実現できないようなケースでは (それにより、システムがほぼ使用不可になる可能性すらある場合)、次のような補完コントロールの使用により妥協し、侵害を軽減できます。In cases where the use of Always Encrypted isn't feasible, or at least not without major costs and efforts that may even render the system near unusable, compromises can be made and mitigated through the use of compensating controls such as:

ベスト プラクティス:Best practices:

  • 開発/テスト環境と運用環境で、別々のアカウントが使用されていることを確認します。Make sure that different accounts are used for Development/Test and Production environments. 別々のアカウントを使用すると、テストと運用のシステムの分離に従うことができます。Different accounts help to comply with separation of Test and Production systems.

  • 個々のユーザーにアクセス許可を割り当てないようにします。Refrain from assigning permissions to individual users. 代わりに、一貫してロール (データベースまたはサーバーのロール) を使用します。Use roles (database or server roles) consistently instead. ロールを使用すると、アクセス許可のレポートとトラブルシューティングに非常に役立ちます。Having roles helps greatly with reporting and troubleshooting permissions.

  • アクセス許可が、必要なアクセス許可に完全に一致する場合は組み込みロールを使用します。複数の組み込みロールのすべてのアクセス許可を合わせると 100% 一致する場合は、複数のロールを同時に割り当てることもできます。Use built-in roles when the permissions match exactly the needed permissions – if the union of all permissions from multiple built-in roles leads to a 100% match, you can assign multiple roles concurrently as well.

  • 組み込みロールで付与されるアクセス許可が多すぎる場合や不十分な場合は、ユーザー定義ロールを作成して使用します。Create and use user-defined roles when built-in roles grant too many permissions or insufficient permissions.

  • ロールの割り当ては、T-SQL の SQL エージェント ジョブ ステップ内で、または Azure ロール用の Azure PIM を使用して一時的に行うこともできます。これは、動的な職務の分離 (DSD) とも呼ばれます。Role assignments can also be done temporarily, also known as Dynamic Separation of Duties (DSD), either within SQL Agent Job steps in T-SQL or using Azure PIM for Azure roles.

  • DBA が暗号化キーやキー ストアにアクセスできないことを確認し、次に、キーにアクセスできるセキュリティ管理者がデータベースにアクセスできないことを確認します。Make sure that DBAs don't have access to the encryption keys or key stores, and that Security Administrators with access to the keys have no access to the database in turn. 拡張キー管理 (EKM) を使用すると、このような分離を簡単に実現できます。The use of Extensible Key Management (EKM) can make this separation easier to achieve. Azure Key Vault を使用して EKM を実装できます。Azure Key Vault can be used to implement EKM.

  • セキュリティに関連した操作については、常に監査証跡を取るようにします。Always make sure to have an Audit trail for security-related actions.

  • Azure 組み込みロールの定義を取得して、使用されているアクセス許可を確認し、PowerShell を使用してそれらの抜粋と蓄積に基づいてカスタム ロールを作成することができます。You can retrieve the definition of the Azure built-in roles to see the permissions used and create a custom role based on excerpts and cumulations of these via PowerShell.

  • db_owner データベース ロールのメンバーは、Transparent Data Encryption (TDE) のようなセキュリティ設定を変更したり、SLO を変更したりできるため、このメンバーシップの付与は慎重に行う必要があります。Because any member of the db_owner database role can change security settings like Transparent Data Encryption (TDE), or change the SLO, this membership should be granted with care. ただし、db_owner 特権を必要とする多くのタスクがあります。However, there are many tasks that require db_owner privileges. DB オプションの変更など、データベース設定の変更のようなタスク。Task like changing any database setting such as changing DB options. どのソリューションでも監査が重要な役割を果たします。Auditing plays a key role in any solution.

  • db_owner のアクセス許可を制限することはできません。そのため、管理者アカウントがユーザー データを表示できないようにします。It is not possible to restrict permissions of a db_owner, and therefore prevent an administrative account from viewing user data. データベース内に非常に機密性の高いデータがある場合は、Always Encrypted を使用すると、db_owner や他の DBA がそれを表示するのを安全に防止できます。If there's highly sensitive data in a database, Always Encrypted can be used to safely prevent db_owners or any other DBA from viewing it.

注意

セキュリティ関連またはトラブルシューティングのタスクでは、職務の分離 (SoD) を実現することは困難です。Achieving Separation of Duties (SoD) is challenging for security-related or troubleshooting tasks. 開発やエンドユーザーのロールのようなその他の領域では、分離が容易になります。Other areas like development and end-user roles are easier to segregate. 多くのコンプライアンスに関連した制御では、他のソリューションが実用的でない場合、監査などの代替制御機能を使用できます。Most compliance related controls allow the use of alternate control functions such as Auditing when other solutions aren't practical.

SoD についてより深く知りたい読者には、次のリソースをお勧めします。For the readers that want to dive deeper into SoD, we recommend the following resources:

通常のコード レビューを実行するPerform regular code reviews

次で言及されています: PCI:6.3.2、SOC:SDL-3Mentioned in: PCI: 6.3.2, SOC: SDL-3

職務の分離は、データベース内のデータに限定されず、アプリケーション コードも含まれます。Separation of Duties is not limited to the data in a database, but includes application code. 悪意のあるコードが、セキュリティ制御をくぐり抜ける可能性があります。Malicious code can potentially circumvent security controls. カスタム コードを運用環境にデプロイする前に、デプロイされる内容を確認する必要があります。Before deploying custom code to production, it is essential to review what's being deployed.

実装方法:How to implement:

  • ソース管理をサポートする Azure Data Studio のようなデータベース ツールを使用します。Use a database tool like Azure Data Studio that supports source control.

  • 分離されたコード デプロイ プロセスを実装します。Implement a segregated code deployment process.

  • メイン ブランチにコミットする前に、(コード自体の作成者以外の) ユーザーが、特権の昇格の可能性に関するリスクや悪意のあるデータ変更がないかコードを検査して、不正および悪意のあるアクセスから保護する必要があります。Before committing to main branch, a person (other than the author of the code itself) has to inspect the code for potential elevation of privileges risks as well as malicious data modifications to protect against fraud and rogue access. これは、ソース管理メカニズムを使用して実行できます。This can be done using source control mechanisms.

ベスト プラクティス:Best practices:

  • 標準化: すべてのコード更新で従うべき標準的手順を実装すると役立ちます。Standardization: It helps to implement a standard procedure that is to be followed for any code updates.

  • 脆弱性評価には、過剰なアクセス許可、古い暗号化アルゴリズムの使用、およびデータベース スキーマ内のその他のセキュリティ問題についてチェックする規則が含まれています。Vulnerability Assessment contains rules that check for excessive permissions, the use of old encryption algorithms, and other security problems within a database schema.

  • SQL インジェクションに対して脆弱なコードがないかスキャンする Advanced Threat Protection を使用して、QA やテスト環境でさらなるチェックを行うことができます。Further checks can be done in a QA or test environment using Advanced Threat Protection that scans for code that is vulnerable to SQL-injection.

  • 注意すべき内容の例を次に示します。Examples of what to look out for:

    • 自動化された SQL コード更新デプロイ内からのユーザーの作成またはセキュリティ設定の変更。Creation of a user or changing security settings from within an automated SQL-code-update deployment.
    • 指定されたパラメーターに応じて、規則に従わない方法でセル内の通貨値を更新するストアド プロシージャ。A stored procedure, which, depending on the parameters provided, updates a monetary value in a cell in a non-conforming way.
  • レビューを行うユーザーが、元のコード作成者以外の個人であり、コード レビューと安全なコーディングに関する知識を持っていることを確認します。Make sure the person conducting the review is an individual other than the originating code author and knowledgeable in code-reviews and secure coding.

  • コード変更のすべてのソースを必ず把握するようにします。Be sure to know all sources of code-changes. コードは T-SQL スクリプトに記述できます。Code can be in T-SQL Scripts. ビュー、関数、トリガー、ストアド プロシージャの形式で実行または配置されるアドホック コマンドです。It can be ad-hoc commands to be executed or be deployed in forms of Views, Functions, Triggers, and Stored Procedures. SQL Agent ジョブ定義 (ステップ) に含めることができます。It can be part of SQL Agent Job definitions (Steps). また、SSIS パッケージ、Azure Data Factory、およびその他のサービス内から実行することもできます。It can also be executed from within SSIS packages, Azure Data Factory, and other services.

データ保護Data protection

データ保護は、暗号化や難読化によって、重要な情報が侵害されないように保護するための一連の機能です。Data protection is a set of capabilities for safeguarding important information from compromise by encryption or obfuscation.

注意

Microsoft は、Azure SQL Database、SQL Managed Instance が FIPS 140-2 レベル 1 に準拠していることを証明します。Microsoft attests to Azure SQL Database and SQL Managed Instance as being FIPS 140-2 Level 1 compliant. これは、FIPS 140-2 レベル 1 の許容されるアルゴリズムと、それらのアルゴリズムの FIPS 140-2 レベル 1 検証済みインスタンスの厳密な使用 (必要なキー長、キー管理、キー生成、およびキーの格納に関する整合性など) を検証した後に行われます。This is done after verifying the strict use of FIPS 140-2 Level 1 acceptable algorithms and FIPS 140-2 Level 1 validated instances of those algorithms including consistency with required key lengths, key management, key generation, and key storage. この証明は、データの処理またはシステムやアプリケーションの提供において、FIPS 140-2 レベル 1 検証済みインスタンスの使用の必要性または要件にお客様が対応できるようにすることを目的としています。This attestation is meant to allow our customers to respond to the need or requirement for the use of FIPS 140-2 Level 1 validated instances in the processing of data or delivery of systems or applications. Microsoft では、米国およびカナダ政府で使用されている別の用語 "FIPS 140-2 レベル 1 検証済み" に対する意図された適用性を示すために、上記のステートメントで使用されている "FIPS 140-2 レベル 1 準拠" と "FIPS 140-2 レベル 1 コンプライアンス" という用語を定義しています。We define the terms "FIPS 140-2 Level 1 compliant" and "FIPS 140-2 Level 1 compliance" used in the above statement to demonstrate their intended applicability to U.S. and Canadian government use of the different term "FIPS 140-2 Level 1 validated."

転送中のデータを暗号化するEncrypt data in transit

次で言及されています: OSA プラクティス #6、ISO コントロール ファミリCryptographyMentioned in: OSA Practice #6, ISO Control Family: Cryptography

クライアントとサーバーの間でデータが移動している間、データを保護します。Protects your data while data moves between your client and server. ネットワークのセキュリティ」を参照してください。Refer to Network Security.

保存データを暗号化Encrypt data at rest

次で言及されています: OSA プラクティス #6、ISO コントロール ファミリCryptographyMentioned in: OSA Practice #6, ISO Control Family: Cryptography

保存時の暗号化は、データベース、ログ、およびバックアップ ファイルに保存されているときのデータの暗号化保護です。Encryption at rest is the cryptographic protection of data when it is persisted in database, log, and backup files.

実装方法:How to implement:

  • サービス マネージド キーを使用した Transparent Database Encryption (TDE) は、2017 年より後に Azure SQL Database および SQL Managed Instance で作成されたすべてのデータベースに対して既定で有効になっています。Transparent Database Encryption (TDE) with service managed keys are enabled by default for any databases created after 2017 in Azure SQL Database and SQL Managed Instance.
  • マネージド インスタンスで、オンプレミス サーバーを使用した復元操作からデータベースが作成された場合は、元のデータベースの TDE 設定が使用されます。In a managed instance, if the database is created from a restore operation using an on-premises server, the TDE setting of the original database will be honored. 元のデータベースで TDE が有効になっていない場合は、マネージド インスタンスに対して手動で TDE を有効にすることをお勧めします。If the original database doesn't have TDE enabled, we recommend that TDE be manually turned on for the managed instance.

ベスト プラクティス:Best practices:

  • 保存時の暗号化を必要とするデータをマスター データベースに格納しないでください。Don't store data that requires encryption-at-rest in the master database. マスター データベースは、TDE を使用して暗号化できません。The master database can't be encrypted with TDE.

  • TDE 保護に対して透過性を高め、きめ細かい制御を行う必要がある場合は、Azure Key Vault 内のカスタマー マネージド キーを使用します。Use customer-managed keys in Azure Key Vault if you need increased transparency and granular control over the TDE protection. Azure Key Vault では、いつでもアクセス許可を取り消して、データベースをアクセス不可にすることができます。Azure Key Vault allows the ability to revoke permissions at any time to render the database inaccessible. TDE 保護機能を他のキーと共に中央で管理したり、Azure Key Vault を使用して独自のスケジュールで TDE 保護機能をローテーションしたりすることができます。You can centrally manage TDE protectors along with other keys, or rotate the TDE protector at your own schedule using Azure Key Vault.

  • Azure Key Vault でカスタマー マネージド キーを使用する場合は、Azure Key Vault で TDE を構成するためのガイドラインAzure Key Vault で Geo-DR を構成する方法に関する記事に従ってください。If you're using customer-managed keys in Azure Key Vault, follow the articles, Guidelines for configuring TDE with Azure Key Vault and How to configure Geo-DR with Azure Key Vault.

高い特権を持つ承認されていないユーザーから、使用中の機密データを保護するProtect sensitive data in use from high-privileged, unauthorized users

使用中のデータとは、SQL クエリの実行中にデータベース システムのメモリに格納されたデータです。Data in use is the data stored in memory of the database system during the execution of SQL queries. データベースに機密データが格納されている場合、組織は、特権の高いユーザーがデータベース内の機密データを表示できないようにすることが必要な場合があります。If your database stores sensitive data, your organization may be required to ensure that high-privileged users are prevented from viewing sensitive data in your database. 組織の Microsoft オペレーターや DBA などの高い特権を持つユーザーは、データベースを管理できる必要がありますが、SQL プロセスのメモリからの機密データの表示や流出の可能性、データベースに対するクエリの実行を防止する必要があります。High-privilege users, such as Microsoft operators or DBAs in your organization should be able to manage the database, but prevented from viewing and potentially exfiltrating sensitive data from the memory of the SQL process or by querying the database.

どのデータが機密であるかや、機密データをメモリ内で暗号化して管理者がプレーンテキストで使用できないようにするかどうかを判定するポリシーは、お客様の組織とお客様が準拠する必要がある法令遵守規定に固有です。The policies that determine which data is sensitive and whether the sensitive data must be encrypted in memory and not accessible to administrators in plaintext, are specific to your organization and compliance regulations you need to adhere to. 関連する要件を確認してください (「機密データを特定してタグを付ける」)。Please see the related requirement: Identify and tag sensitive data.

実装方法:How to implement:

  • Always Encrypted を使用して、メモリ内にある場合や使用中であっても、機密データが Azure SQL Database または SQL Managed Instance にプレーンテキストで確実に公開されないようにします。Use Always Encrypted to ensure sensitive data isn't exposed in plaintext in Azure SQL Database or SQL Managed Instance, even in memory/in use. Always Encrypted により、データベース管理者 (DBA) とクラウド管理者 (または、高い特権を持つが未承認のユーザーを偽装できる悪意のあるアクター) からデータを保護し、データにアクセスできるユーザーをより細かく制御できます。Always Encrypted protects the data from Database Administrators (DBAs) and cloud admins (or bad actors who can impersonate high-privileged but unauthorized users) and gives you more control over who can access your data.

ベスト プラクティス:Best practices:

  • Always Encrypted は、保存データ (TDE) または転送中のデータ (SSL/TLS) の暗号化の代替ではありません。Always Encrypted isn't a substitute to encrypt data at rest (TDE) or in transit (SSL/TLS). パフォーマンスと機能への影響を最小限に抑えるため、機密データ以外のデータには Always Encrypted を使用しないでください。Always Encrypted shouldn't be used for non-sensitive data to minimize performance and functionality impact. 保存時、転送中、使用中のデータを包括的に保護するには、TDE およびトランスポート層セキュリティ (TLS) と組み合わせて Always Encrypted を使用することをお勧めします。Using Always Encrypted in conjunction with TDE and Transport Layer Security (TLS) is recommended for comprehensive protection of data at-rest, in-transit, and in-use.

  • Always Encrypted を運用データベースにデプロイする前に、特定された機密データ列の暗号化による影響を評価します。Assess the impact of encrypting the identified sensitive data columns before you deploy Always Encrypted in a production database. Always Encrypted では通常、暗号化された列でクエリの機能性が低下します。また、「Always Encrypted」の「機能の詳細」に記載されているその他の制限事項があります。In general, Always Encrypted reduces the functionality of queries on encrypted columns and has other limitations, listed in Always Encrypted - Feature Details. そのため場合によっては、クエリでサポートされていない機能をクライアント側に再実装するためにアプリケーションを再設計したり、ストアド プロシージャ、関数、ビュー、トリガーなど、データベース スキーマをリファクターしたりする必要があります。Therefore, you may need to rearchitect your application to re-implement the functionality, a query does not support, on the client side or/and refactor your database schema, including the definitions of stored procedures, functions, views and triggers. Always Encrypted の制約と制限に準拠していない既存のアプリケーションでは、暗号化された列を使用できない場合があります。Existing applications may not work with encrypted columns if they do not adhere to the restrictions and limitations of Always Encrypted. Always Encrypted がサポートされる Microsoft のツール、製品、サービスのエコシステムは拡大しつつありますが、それらの一部では暗号化された列を使用できません。While the ecosystem of Microsoft tools, products and services supporting Always Encrypted is growing, a number of them do not work with encrypted columns. ワークロードの特性によっては、列の暗号化がクエリのパフォーマンスに影響を及ぼす場合もあります。Encrypting a column may also impact query performance, depending on the characteristics of your workload.

  • Always Encrypted を使用して悪意のある DBA からデータを保護する場合は、役割の分離を使って Always Encrypted キーを管理します。Manage Always Encrypted keys with role separation if you're using Always Encrypted to protect data from malicious DBAs. 役割の分離を使用する場合、セキュリティ管理者が物理キーを作成します。With role separation, a security admin creates the physical keys. DBA は、データベースに物理キーを記述する列マスター キーと列暗号化キー メタデータ オブジェクトを作成します。The DBA creates the column master key and column encryption key metadata objects describing the physical keys in the database. この処理中、セキュリティ管理者はデータベースにアクセスする必要はなく、DBA はプレーンテキストの物理キーにアクセスする必要はありません。During this process, the security admin doesn't need access to the database, and the DBA doesn't need access to the physical keys in plaintext.

  • 管理を容易にするために、列マスター キーを Azure Key Vault に格納します。Store your column master keys in Azure Key Vault for ease of management. キー管理を難しくする Windows 証明書ストア (および一般的に、中央キー管理ソリューションとは対照的な分散キー ストア ソリューション) は使用しないようにしてください。Avoid using Windows Certificate Store (and in general, distributed key store solutions, as opposed central key management solutions) that make key management hard.

  • 複数のキー (列マスター キーまたは列暗号化キー) を使用した場合のトレードオフについて、慎重に検討してください。Think carefully through the tradeoffs of using multiple keys (column master key or column encryption keys). キー管理コストを削減するために、キーの数は少なく保つようにしてください。Keep the number of keys small to reduce key management cost. 通常、データベースごとに 1 つの列マスター キーと 1 つの列暗号化キーがあれば、(キー ローテーションの途中でなければ) 安定状態の環境では十分です。One column master key and one column encryption key per database is typically sufficient in steady-state environments (not in the middle of a key rotation). 複数のユーザー グループがあり、それぞれ異なるキーを使用し、異なるデータにアクセスする場合は、追加のキーが必要になる場合があります。You may need additional keys if you have different user groups, each using different keys and accessing different data.

  • 列マスター キーは、コンプライアンス要件に従ってローテーションさせます。Rotate column master keys per your compliance requirements. 列暗号化キーもローテーションする必要がある場合は、アプリケーションのダウンタイムを最小限に抑えるためにオンライン暗号化を使用することを検討してください。If you also need to rotate column encryption keys, consider using online encryption to minimize application downtime.

  • データの計算 (等値) をサポートする必要がある場合は、決定論的な暗号化を使用します。Use deterministic encryption if computations (equality) on data need to be supported. それ以外の場合は、ランダム化された暗号化を使用します。Otherwise, use randomized encryption. 低エントロピのデータ セットや、公に知られているディストリビューションがあるデータ セットには、決定論的な暗号化を使用しないようにしてください。Avoid using deterministic encryption for low-entropy data sets, or data sets with publicly known distribution.

  • 第三者が同意なしにデータに合法的にアクセスすることが懸念される場合は、プレーンテキストのキーとデータにアクセスできるすべてのアプリケーションとツールが Microsoft Azure Cloud の外部で実行されるようにします。If you're concerned about third parties accessing your data legally without your consent, ensure that all application and tools that have access to the keys and data in plaintext run outside of Microsoft Azure Cloud. キーにアクセスできなければ、暗号化をバイパスしない限り、第三者がデータの暗号化を解除することはできません。Without access to the keys, the third party will have no way of decrypting the data unless they bypass the encryption.

  • Always Encrypted では、キー (および保護されたデータ) への一時的アクセスの付与は容易にはサポートされません。Always Encrypted doesn't easily support granting temporary access to the keys (and the protected data). たとえば、キーを DBA と共有して、DBA が機密データおよび暗号化されたデータに対して何らかのクレンジング操作を実行できるようにする必要がある場合があります。For example, if you need to share the keys with a DBA to allow the DBA to do some cleansing operations on sensitive and encrypted data. DBA からのデータへのアクセスを確実に取り消す唯一の方法は、データを保護する列暗号化キーと列マスター キーの両方を回転することですが、これはコストのかかる操作です。The only way to reliability revoke the access to the data from the DBA will be to rotate both the column encryption keys and the column master keys protecting the data, which is an expensive operation.

  • 暗号化された列のプレーンテキスト値にアクセスするには、ユーザーは、列を保護する列マスター キー (CMK) にアクセスできる必要があります。これは、CMK が保持されているキー ストアに構成されています。To access the plaintext values in encrypted columns, a user needs to have access to the Column Master Key (CMK) that protects columns, which is configured in the key store holding the CMK. また、ユーザーには、 [列マスター キー定義を表示する][列暗号化キー定義を表示する] のデータベース権限が必要です。The user also needs to have the VIEW ANY COLUMN MASTER KEY DEFINITION and VIEW ANY COLUMN ENCRYPTION KEY DEFINITION database permissions.

暗号化によってアプリケーション ユーザーの機密データへのアクセスを制御するControl access of application users to sensitive data through encryption

暗号化は、暗号化キーにアクセスできる特定のアプリケーション ユーザーのみがデータを表示また更新できるようにするための方法として使用できます。Encryption can be used as a way to ensure that only specific application users who have access to cryptographic keys can view or update the data.

実装方法:How to implement:

  • セル レベルの暗号化 (CLE) を使用します。Use Cell-level Encryption (CLE). 詳細については、「データの列の暗号化」という記事を参照してください。See the article, Encrypt a Column of Data for details.
  • Always Encrypted を使用してください。ただし、制限事項には注意してください。Use Always Encrypted, but be aware of its limitation. 制限事項を次に示します。The limitations are listed below.

ベスト プラクティスBest practices

CLE を使用する場合:When using CLE:

  • SQL のアクセス許可とロールを使用して、キーへのアクセスを制御します。Control access to keys through SQL permissions and roles.

  • データの暗号化には AES (AES 256 を推奨) を使用します。Use AES (AES 256 recommended) for data encryption. RC4、DES、TripleDES などのアルゴリズムは非推奨であり、既知の脆弱性があるため、使用しないでください。Algorithms, such RC4, DES and TripleDES, are deprecated and shouldn't be used because of known vulnerabilities.

  • 3DES の使用を回避するため、非対称キー/証明書 (パスワードではない) を使用して対称キーを保護します。Protect symmetric keys with asymmetric keys/certificates (not passwords) to avoid using 3DES.

  • エクスポート/インポート (bacpac ファイル) でセル レベルの暗号化を使用してデータベースを移行するときは注意してください。Be careful when migrating a database using Cell-Level Encryption via export/import (bacpac files).

Always Encrypted が、基本的に、使用中の機密データを Azure SQL Database の高い特権を持つユーザー (クラウド オペレーター、DBA) から保護するように設計されていることに留意してください。「高い特権を持つ承認されていないユーザーから、使用中の機密データを保護する」を参照してください。Keep in mind that Always Encrypted is primarily designed to protect sensitive data in use from high-privilege users of Azure SQL Database (cloud operators, DBAs) - see Protect sensitive data in use from high-privileged, unauthorized users. Always Encrypted を使用してアプリケーション ユーザーからデータを保護する場合は、次の課題に注意してください。Be aware of the following challenges when using Always Encrypted to protect data from application users:

  • 既定で、Always Encrypted をサポートするすべての Microsoft クライアント ドライバーは、列暗号化キーのグローバル (アプリケーションごとに 1 つ) のキャッシュを保持しています。By default, all Microsoft client drivers supporting Always Encrypted maintain a global (one per application) cache of column encryption keys. クライアント ドライバーが列マスター キーを保持しているキー ストアに接続して、プレーンテキスト列の暗号化キーを取得すると、そのプレーンテキスト列の暗号化キーはキャッシュされます。Once a client driver acquires a plaintext column encryption key by contacting a key store holding a column master key, the plaintext column encryption key is cached. そのため、マルチユーザー アプリケーションのユーザーからデータを分離することは困難になります。This makes isolating data from users of a multi-user application challenging. アプリケーションがキー ストア (Azure Key Vault など) と対話するときにエンド ユーザーを偽装すると、ユーザーのクエリによって列暗号化キーがキャッシュに取り込まれた後、同じキーを必要とするが、別のユーザーによってトリガーされる後続のクエリでは、キャッシュされたキーが使用されます。If your application impersonates end users when interacting with a key store (such as Azure Key Vault), after a user's query populates the cache with a column encryption key, a subsequent query that requires the same key but is triggered by another user will use the cached key. ドライバーはキー ストアを呼び出さず、2 番目のユーザーが列暗号化キーにアクセスする権限を持っているかどうかはチェックされません。The driver won't call the key store and it won't check if the second user has a permission to access the column encryption key. その結果、ユーザーがキーへのアクセス権を持っていない場合でも、そのユーザーは暗号化されたデータを表示できます。As a result, the user can see the encrypted data even if the user doesn't have access to the keys. マルチユーザー アプリケーション内のユーザーを分離するには、列暗号化キーのキャッシュを無効にします。To achieve the isolation of users within a multi-user application, you can disable column encryption key caching. キャッシュを無効にすると、パフォーマンスのオーバーヘッドが増えます。これは、データの暗号化または復号化の操作ごとに、ドライバーがキーストアに接続する必要があるためです。Disabling caching will cause additional performance overheads, as the driver will need to contact the key store for each data encryption or decryption operation.

データ形式を維持しながら、アプリケーション ユーザーによる承認されていない表示からデータを保護するProtect data against unauthorized viewing by application users while preserving data format

承認されていないユーザーがデータを表示するのを防ぐもう 1 つの方法は、ユーザー アプリケーションが引き続きデータを処理および表示できるようにデータの型と形式を維持しながら、データを難読化またはマスクすることです。Another technique for preventing unauthorized users from viewing data is to obfuscate or mask the data while preserving data types and formats to ensure that user applications can continue handle and display the data.

実装方法:How to implement:

注意

Always Encrypted は、動的データ マスクでは機能しません。Always Encrypted does not work with Dynamic Data Masking. 同じ列を暗号化してマスクすることはできません。つまり、使用中のデータを保護することと、動的データ マスクによってアプリ ユーザーのデータをマスクすることのどちらを優先するかを決める必要があります。It is not possible to encrypt and mask the same column, which implies that you need to prioritize protecting data in use vs. masking the data for your app users via Dynamic Data Masking.

ベスト プラクティス:Best practices:

注意

動的データ マスクを使用して、高い特権を持つユーザーからデータを保護することはできません。Dynamic Data Masking cannot be used to protect data from high-privilege users. マスク ポリシーは、db_owner のような管理者アクセス権を持つユーザーには適用されません。Masking policies do not apply to users with administrative access like db_owner.

  • アプリ ユーザーにアドホック クエリの実行を許可しないでください (動的データ マスクを回避できる可能性があるからです)。Don't permit app users to run ad-hoc queries (as they may be able to work around Dynamic Data Masking).

  • (SQL アクセス許可、ロール、RLS を介した) 適切なアクセス制御ポリシーを使用して、マスクされた列で更新を行うユーザー アクセス許可を制限します。Use a proper access control policy (via SQL permissions, roles, RLS) to limit user permissions to make updates in the masked columns. 列にマスクを作成しても、その列への更新は防止されません。Creating a mask on a column doesn't prevent updates to that column. マスクされた列のクエリを実行するときにマスクされたデータを受け取るユーザーは、書き込みアクセス許可を持っている場合はデータを更新できます。Users that receive masked data when querying the masked column, can update the data if they have write-permissions.

  • 動的データ マスクは、マスクされた値の統計的特性を保持しません。Dynamic Data Masking doesn't preserve the statistical properties of the masked values. これは、クエリ結果に影響する場合があります (たとえば、マスクされたデータのフィルター述語や結合を含むクエリ)。This may impact query results (for example, queries containing filtering predicates or joins on the masked data).

ネットワークのセキュリティNetwork security

ネットワークのセキュリティとは、Azure SQL Database に転送中のデータをセキュリティで保護するためのアクセス制御とベスト プラクティスを指します。Network security refers to access controls and best practices to secure your data in transit to Azure SQL Database.

SQL Database または SQL Managed Instance に安全に接続するようにクライアントを構成するConfigure my client to connect securely to SQL Database/SQL Managed Instance

既知の脆弱性 (たとえば、古い TLS プロトコルと暗号スイートを使用するなど) があるクライアント マシンとアプリケーションが Azure SQL Database および SQL Managed Instance に接続できないようにする方法のベスト プラクティス。Best practices on how to prevent client machines and applications with well-known vulnerabilities (for example, using older TLS protocols and cipher suites) from connecting to Azure SQL Database and SQL Managed Instance.

実装方法:How to implement:

ベスト プラクティス:Best practices:

  • 暗号化を有効にしてすべてのアプリとツールを SQL Database に接続するように構成しますConfigure all your apps and tools to connect to SQL Database with encryption enabled

    • Encrypt = On、TrustServerCertificate = Off (または Microsoft 以外のドライバーでの同等のもの)。Encrypt = On, TrustServerCertificate = Off (or equivalent with non-Microsoft drivers).
  • アプリが、TLS をサポートしていないドライバーを使用している場合や古いバージョンの TLS をサポートしている場合は、可能であればドライバーを置き換えます。If your app uses a driver that doesn't support TLS or supports an older version of TLS, replace the driver, if possible. 可能でない場合は、セキュリティ上のリスクを慎重に評価してください。If not possible, carefully evaluate the security risks.

  • トランスポート層セキュリティ (TLS) レジストリ設定に従って、Azure SQL Database に接続しているクライアント コンピューターで SSL 2.0、SSL 3.0、TLS 1.0、および TLS 1.1 を無効にすることにより、それらの脆弱性による攻撃ベクトルを減らします。Reduce attack vectors via vulnerabilities in SSL 2.0, SSL 3.0, TLS 1.0, and TLS 1.1 by disabling them on client machines connecting to Azure SQL Database per Transport Layer Security (TLS) registry settings.

  • クライアント上で使用できる暗号スイートを確認します。TLS/SSL (Schannel SSP) の暗号スイートCheck cipher suites available on the client: Cipher Suites in TLS/SSL (Schannel SSP). 具体的には、TLS の暗号スイートの順序の構成に関する記事に従って 3DES を無効にします。Specifically, disable 3DES per Configuring TLS Cipher Suite Order.

  • Azure SQL Database および SQL Managed Instance の場合、暗号化はプロキシとリダイレクトの両方の接続の種類に適用されます。For Azure SQL Database and SQL Managed Instance, encryption is enforced for both Proxy and Redirect connection types. Azure SQL Managed Instance の場合は、 [プロキシ] の接続の種類 (既定) を使用します。これにより、サーバー側から暗号化が実施されます。For Azure SQL Managed Instance, use the Proxy connection type (default) as this enforces encryption from the server side. [リダイレクト] の接続の種類は、現在、暗号化の実施をサポートしておらず、プライベート IP 接続でのみ使用可能です。The Redirect connection type currently doesn't support encryption enforcement and is only available on private IP connections.

  • 詳細については、Azure SQL Database の接続アーキテクチャに関するページの「接続ポリシー」を参照してください。For more information, see Azure SQL Database Connectivity Architecture - Connection policy.

攻撃対象領域を最小限にするMinimize attack surface

悪意のあるユーザーから攻撃される可能性のある機能の数を最小限にします。Minimize the number of features that can be attacked by a malicious user. Azure SQL Database のネットワーク アクセス制御を実装します。Implement network access controls for Azure SQL Database.

次で言及されています: OSA プラクティス #5Mentioned in: OSA Practice #5

実装方法:How to implement:

SQL Database:In SQL Database:

  • サーバー レベルで [Azure サービスへのアクセスを許可] を [オフ] に設定します。Set Allow Access to Azure services to OFF at the server-level
  • VNet サービス エンドポイントと VNet ファイアウォール規則を使用します。Use VNet Service endpoints and VNet Firewall Rules.
  • Private Link (プレビュー) を使用します。Use Private Link (preview).

SQL Managed Instance の場合:In SQL Managed Instance:

ベスト プラクティス:Best practices:

  • (たとえば、プライベート データ パスを使用して) プライベート エンドポイントで接続することにより、Azure SQL Database および SQL Managed Instance へのアクセスを制限します。Restricting access to Azure SQL Database and SQL Managed Instance by connecting on a private endpoint (for example, using a private data path):

    • マネージド インスタンスは、外部アクセスを防ぐために、仮想ネットワーク内で分離することができます。A managed instance can be isolated inside a virtual network to prevent external access. 同じリージョン内の同じまたはピアリングされた仮想ネットワークにあるアプリケーションとツールは、直接アクセスできます。Applications and tools that are in the same or peered virtual network in the same region could access it directly. 異なるリージョンにあるアプリケーションとツールは、仮想ネットワーク間接続や ExpressRoute 回線のピアリングを使用して接続を確立できます。Applications and tools that are in different region could use virtual-network-to-virtual-network connection or ExpressRoute circuit peering to establish connection. ユーザーは、ネットワーク セキュリティ グループ (NSG) を使用して、ポート 1433 でのアクセスを、マネージド インスタンスへのアクセスを必要とするリソースのみに制限する必要があります。Customer should use Network Security Groups (NSG) to restrict access over port 1433 only to resources that require access to a managed instance.
    • SQL Database については、仮想ネットワーク内のサーバーに専用のプライベート IP を提供する Private Link 機能を使用します。For a SQL Database, use the Private Link feature that provides a dedicated private IP for the server inside your virtual network. また、仮想ネットワークのファイアウォール規則と共に仮想ネットワーク サービス エンドポイントを使用して、ご使用のサーバーへのアクセスを制限することもできます。You can also use Virtual network service endpoints with virtual network firewall rules to restrict access to your servers.
    • モバイル ユーザーは、ポイント対サイト VPN 接続を使用して、データ パス経由で接続する必要があります。Mobile users should use point-to-site VPN connections to connect over the data path.
    • オンプレミス ネットワークに接続されているユーザーは、サイト間 VPN 接続または ExpressRoute を使用して、データ パス経由で接続する必要があります。Users connected to their on-premises network should use site-to-site VPN connection or ExpressRoute to connect over the data path.
  • パブリック エンドポイントに接続することで (たとえば、パブリック データ パスを使用して) Azure SQL Database および SQL Managed Instance にアクセスできます。You can access Azure SQL Database and SQL Managed Instance by connecting to a public endpoint (for example, using a public data path). 次のベスト プラクティスを検討してください。The following best practices should be considered:

注意

SQL Managed Instance のパブリック エンドポイントは、既定では有効になっておらず、明示的に有効にする必要があります。The SQL Managed Instance public endpoint is not enabled by default and it and must be explicitly enabled. 会社のポリシーでパブリック エンドポイントの使用が禁止されている場合は、最初に Azure Policy を使用して、パブリック エンドポイントを有効にしないようにします。If company policy disallows the use of public endpoints, use Azure Policy to prevent enabling public endpoints in the first place.

SQL Database または SQL Managed Instance へのセキュリティで保護された接続用に Power BI を構成するConfigure Power BI for secure connections to SQL Database/SQL Managed Instance

ベスト プラクティス:Best practices:

SQL Database または SQL Managed Instance へのセキュリティで保護された接続用に App Service を構成するConfigure App Service for secure connections to SQL Database/SQL Managed Instance

ベスト プラクティス:Best practices:

SQL Database または SQL Managed Instance へのセキュリティで保護された接続用に Azure 仮想マシンのホスティングを構成するConfigure Azure virtual machine hosting for secure connections to SQL Database/SQL Managed Instance

ベスト プラクティス:Best practices:

  • Azure 仮想マシンの NSG で許可と拒否の規則を組み合わせて使用して、VM からアクセスできるリージョンを制御します。Use a combination of Allow and Deny rules on the NSGs of Azure virtual machines to control which regions can be accessed from the VM.

  • Azure における IaaS ワークロードのセキュリティに関するベスト プラクティス」という記事に従って VM が構成されていることを確認します。Ensure that your VM is configured per the article, Security best practices for IaaS workloads in Azure.

  • すべての VM が特定の仮想ネットワークおよびサブネットに関連付けられていることを確認します。Ensure that all VMs are associated with a specific virtual network and subnet.

  • 強制トンネリングについて」のガイダンスに従って、既定のルート 0.0.0.0/インターネットが必要かどうかを評価します。Evaluate if you need the default route 0.0.0.0/Internet per the guidance at about forced tunneling.

    • 必要な場合 (たとえば、フロントエンド サブネット) は、既定のルートを保持します。If yes – for example, front-end subnet - then keep the default route.
    • 不要な場合 (たとえば、中間層やバックエンド サブネット) は、強制トンネリングを有効にします。これにより、トラフィックがインターネットを経由してオンプレミスに到達する (つまり、クロスプレミスになる) ことはありません。If no – for example, middle tier or back-end subnet – then enable force tunneling so no traffic goes over Internet to reach on-premises (a.k.a cross-premises).
  • ピアリングを使用しているか、オンプレミスに接続している場合は、省略可能な既定のルートを実装します。Implement optional default routes if you're using peering or connecting to on-premises.

  • パケット検査のために仮想ネットワーク内のすべてのトラフィックをネットワーク仮想アプライアンスに送信する必要がある場合は、ユーザー定義ルートを実装します。Implement User Defined Routes if you need to send all traffic in the virtual network to a Network Virtual Appliance for packet inspection.

  • Azure のバックボーン ネットワーク経由で Azure Storage などの PaaS サービスに安全にアクセスするには、仮想ネットワーク サービス エンドポイントを使用します。Use virtual network service endpoints for secure access to PaaS services like Azure Storage via the Azure backbone network.

分散型サービス拒否 (DDoS) 攻撃から保護するProtect against Distributed Denial of Service (DDoS) attacks

分散型サービス拒否 (DDoS) 攻撃とは、悪意のあるユーザーが、Azure インフラストラクチャを過負荷にし、有効なログインおよびワークロードを拒否させる目的で、Azure SQL Database に大量のネットワーク トラフィックを送信しようとすることです。Distributed Denial of Service (DDoS) attacks are attempts by a malicious user to send a flood of network traffic to Azure SQL Database with the aim of overwhelming the Azure infrastructure and causing it to reject valid logins and workload.

次で言及されています: OSA プラクティス #9Mentioned in: OSA Practice #9

実装方法:How to implement:

DDoS 保護は、Azure プラットフォームの一部として自動的に有効になります。DDoS protection is automatically enabled as part of the Azure Platform. これには、パブリック エンドポイントでのネットワーク レベル攻撃に対する常時オンのトラフィック監視とリアルタイム軽減策が含まれます。It includes always-on traffic monitoring and real-time mitigation of network-level attacks on public endpoints.

ベスト プラクティス:Best practices:

  • 攻撃対象領域を最小限にする」で説明されているプラクティスに従うことで、DDoS 攻撃の脅威を最小限にすることができます。Follow the practices described in Minimize Attack Surface helps minimize DDoS attack threats.

  • Advanced Threat Protection の Brute force SQL credentials (SQL 資格情報に対するブルート フォース攻撃) アラートは、ブルート フォース攻撃の検出に役立ちます。The Advanced Threat Protection Brute force SQL credentials alert helps to detect brute force attacks. 場合によって、アラートは侵入テストのワークロードを区別することもできます。In some cases, the alert can even distinguish penetration testing workloads.

  • SQL Database に接続する Azure VM ホスティング アプリケーションの場合:For Azure VM hosting applications connecting to SQL Database:

    • Azure Security Center でインターネットに接続するエンドポイント経由のアクセスを制限するための推奨事項に従ってください。Follow recommendation to Restrict access through Internet-facing endpoints in Azure Security Center.
    • Azure VM でアプリケーションの複数インスタンスを実行するには、仮想マシン スケール セットを使用します。Use virtual machine scale sets to run multiple instances of your application on Azure VMs.
    • ブルート フォース攻撃を防ぐために、インターネットからの RDP と SSH を無効にします。Disable RDP and SSH from Internet to prevent brute force attack.

監視、ログ、監査Monitoring, Logging, and Auditing

このセクションでは、データベースへのアクセスや悪用を試行する、通常と異なる、害を及ぼす可能性のある試みを示唆する異常なアクティビティを検出するのに役立つ機能について説明します。This section refers to capabilities to help you detect anomalous activities indicating unusual and potentially harmful attempts to access or exploit databases. また、データベース イベントを追跡およびキャプチャするようにデータベース監査を構成するためのベスト プラクティスについても説明します。It also describes best practices to configure database auditing to track and capture database events.

データベースを攻撃から保護するProtect databases against attacks

Advanced Threat Protection を使用すると、異常なアクティビティに対するセキュリティ アラートを提供することで、潜在的な脅威が発生したときにそれを検出して対応することができます。Advanced threat protection enables you to detect and respond to potential threats as they occur by providing security alerts on anomalous activities.

実装方法:How to implement:

  • Advanced Threat Protection for SQL を使用して、通常と異なる、害を及ぼす可能性のあるデータベースへのアクセスや悪用の試行を検出します。たとえば、次のようなものがあります。Use Advanced Threat Protection for SQL to detect unusual and potentially harmful attempts to access or exploit databases, including:
    • SQL インジェクション攻撃。SQL injection attack.
    • 資格情報の盗難または漏洩。Credentials theft/leak.
    • 特権の悪用。Privilege abuse.
    • データ窃盗。Data exfiltration.

ベスト プラクティス:Best practices:

  • 特定のサーバーまたはマネージド インスタンス用に Azure Defender for SQL  を構成します。Configure Azure Defender for SQL for a specific server or a managed instance. Azure Security Center の Standard レベルに切り替えて、サブスクリプション内のすべてのサーバーおよびマネージド インスタンス用に Azure Defender for SQL を構成することもできます。You can also configure Azure Defender for SQL for all servers and managed instances in a subscription by switching to Azure Security Center Standard tier.

  • 完全な調査エクスペリエンスを実現するには、 SQL Database Auditing を有効にすることをお勧めします。For a full investigation experience, it's recommended to enable SQL Database Auditing. 監査を使用すると、データベース イベントを追跡し、Azure Storage アカウントまたは Azure Log Analytics ワークスペースの監査ログに書き込むことができます。With auditing, you can track database events and write them to an audit log in an Azure Storage account or Azure Log Analytics workspace.

重要なセキュリティ イベントを監査するAudit critical security events

データベース イベントを追跡すると、データベース アクティビティを理解するために役立ちます。Tracking of database events helps you understand database activity. ビジネス上の懸念やセキュリティ違反の疑いを示す可能性のある不一致や異常について分析情報を得ることができます。You can gain insight into discrepancies and anomalies that could indicate business concerns or suspected security violations. また、これにより、コンプライアンス基準への準拠を可能にし、促進します。It also enables and facilitates adherence to compliance standards.

実装方法:How to implement:

  • SQL Database 監査または Managed Instance の監査を有効にしてデータベース イベントを追跡し、それらを Azure Storage アカウント、Log Analytics ワークスペース (プレビュー)、または Event Hubs (プレビュー) の監査ログに書き込みます。Enable SQL Database Auditing or Managed Instance Auditing to track database events and write them to an audit log in your Azure Storage account, Log Analytics workspace (preview), or Event Hubs (preview).

  • 監査ログは、Azure Storage アカウント、Log Analytics ワークスペース (Azure Monitor ログで使用)、またはイベント ハブ (イベント ハブで使用) に書き込むことができます。Audit logs can be written to an Azure Storage account, to a Log Analytics workspace for consumption by Azure Monitor logs, or to event hub for consumption using event hub. これらのオプションは組み合わせて構成でき、それぞれの場所に監査ログが書き込まれます。You can configure any combination of these options, and audit logs will be written to each.

ベスト プラクティス:Best practices:

  • イベントを監査するためにサーバーまたは Managed Instance AuditingSQL Database 監査を構成すると、そのサーバー上の既存および新しく作成されたすべてのデータベースが監査されます。By configuring SQL Database Auditing on your server or Managed Instance Auditing to audit events, all existing and newly created databases on that server will be audited.
  • 既定で、監査ポリシーには、データベースに対するすべてのアクション (クエリ、ストアド プロシージャ、成功および失敗したログイン) が含まれます。その結果、大量の監査ログが生成される可能性があります。By default auditing policy includes all actions (queries, stored procedures and successful and failed logins) against the databases, which may result in high volume of audit logs. PowerShell を使用してさまざまな種類のアクションとアクション グループの監査を構成することをお勧めします。It's recommended for customers to configure auditing for different types of actions and action groups using PowerShell. これを構成すると、監査されるアクションの数を制御し、イベント損失のリスクを最小限に抑えることができます。Configuring this will help control the number of audited actions, and minimize the risk of event loss. カスタムの監査構成を使うと、必要な監査データのみをキャプチャできます。Custom audit configurations allow customers to capture only the audit data that is needed.
  • 監査ログは、Azure portal で、または構成されたストレージの場所から直接使用できます。Audit logs can be consumed directly in the Azure portal, or from the storage location that was configured.

注意

Log Analytics に対する監査を有効にすると、インジェストのレートに基づくコストが発生します。Enabling auditing to Log Analytics will incur cost based on ingestion rates. このオプションを使用した場合のコストを承知のうえで利用するか、または、監査ログを Azure ストレージ アカウントに格納することを検討してください。Please be aware of the associated cost with using this option, or consider storing the audit logs in an Azure storage account.

その他のリソース:Further resources:

監査ログをセキュリティで保護するSecure audit logs

ストレージ アカウントへのアクセスを制限して、職務の分離をサポートし、DBA と監査者を分離します。Restrict access to the storage account to support Separation of Duties and to separate DBA from Auditors.

実装方法:How to implement:

  • 監査ログを Azure Storage に保存するときは、ストレージ アカウントへのアクセスが最小限のセキュリティ原則に合わせて制限されていることを確認します。When saving Audit logs to Azure Storage, make sure that access to the Storage Account is restricted to the minimal security principles. ストレージ アカウントにアクセスできるユーザーを制御します。Control who has access to the storage account.
  • 詳細については、Azure Storage へのアクセスの承認に関する記事を参照してください。For more information, see Authorizing access to Azure Storage.

ベスト プラクティス:Best practices:

セキュリティ管理Security Management

このセクションでは、データベースのセキュリティ体制を管理するためのさまざまな側面とベスト プラクティスについて説明します。This section describes the different aspects and best practices for managing your databases security posture. これには、データベースがセキュリティ基準を満たすよう構成されていることを確認するため、およびデータベース内の潜在的な機密データへのアクセスを検出、分類、および追跡するためのベスト プラクティスが含まれます。It includes best practices for ensuring your databases are configured to meet security standards, for discovering and for classifying and tracking access to potentially sensitive data in your databases.

セキュリティのベスト プラクティスに合うようにデータベースが構成されていることを確認するEnsure that the databases are configured to meet security best practices

潜在的なデータベースの脆弱性を検出して修正することにより、データベースのセキュリティを事前に強化します。Proactively improve your database security by discovering and remediating potential database vulnerabilities.

実装方法:How to implement:

  • SQL 脆弱性評価 (VA) を有効にしてデータベースのセキュリティ問題をスキャンし、データベースで定期的に自動実行されるようにします。Enable SQL Vulnerability Assessment (VA) to scan your database for security issues, and to automatically run periodically on your databases.

ベスト プラクティス:Best practices:

  • 最初に、データベース上で VA を実行し、セキュリティのベスト プラクティスに反する失敗したチェックを修正して繰り返します。Initially, run VA on your databases and iterate by remediating failing checks that oppose security best practices. スキャンが "クリーン" になるか、すべてのチェックに合格するまで、許容される構成のベースラインを設定します。Set up baselines for acceptable configurations until the scan comes out clean, or all checks has passed.

  • 定期的な反復スキャンを 1 週間に 1 回実行するように構成し、関係者が概要のメールを受信するように構成します。Configure periodic recurring scans to run once a week and configure the relevant person to receive summary emails.

  • 毎週スキャンするたびに、VA の概要を確認します。Review the VA summary following each weekly scan. 見つかった脆弱性について、以前のスキャン結果からのドリフトを評価し、チェックを解決する必要があるかどうかを判断します。For any vulnerabilities found, evaluate the drift from the previous scan result and determine if the check should be resolved. 構成の変更に正当な理由があるかどうかを確認します。Review if there's a legitimate reason for the change in configuration.

  • チェックを解決し、関連するベースラインを更新します。Resolve checks and update baselines where relevant. アクションを解決するためのチケット項目を作成し、それらが解決されるまで追跡します。Create ticket items for resolving actions and track these until they're resolved.

その他のリソース:Further resources:

機密データを特定してタグを付けるIdentify and tag sensitive data

機密データが含まれている可能性がある列を検出します。Discover columns that potentially contain sensitive data. 何が機密データとみなされるかは、お客様や遵守すべき規則などによって大きく異なり、そのデータを所管するユーザーによって評価される必要があります。What is considered sensitive data heavily depends on the customer, compliance regulation, etc., and needs to be evaluated by the users in charge of that data. 機密度に基づく高度な監査と保護のシナリオを使用するために、列を分類します。Classify the columns to use advanced sensitivity-based auditing and protection scenarios.

実装方法:How to implement:

  • SQL データの検出と分類を使用して、データベース内の機密データを検出、分類、ラベル付け、および保護します。Use SQL Data Discovery and Classification to discover, classify, label, and protect the sensitive data in your databases.
    • [SQL Data Discovery and Classification](SQL データの検出と分類) ダッシュボードで、自動検出によって作成された分類の推奨事項を確認します。View the classification recommendations that are created by the automated discovery in the SQL Data Discovery and Classification dashboard. 機密データに分類ラベルが永続的にタグ付けされるように、関連する分類を受け入れます。Accept the relevant classifications, such that your sensitive data is persistently tagged with classification labels.
    • 自動メカニズムによって検出されなかったその他の機密データ フィールドについては、手動で分類を追加します。Manually add classifications for any additional sensitive data fields that were not discovered by the automated mechanism.
  • 詳しくは、「SQL データの検出と分類」をご覧ください。For more information, see SQL Data Discovery and Classification.

ベスト プラクティス:Best practices:

  • データベースの分類状態を正確に評価するために、分類ダッシュボードを定期的に監視します。Monitor the classification dashboard on a regular basis for an accurate assessment of the database’s classification state. コンプライアンスと監査の目的で、データベースの分類状態に関するレポートをエクスポートまたは印刷して共有することができます。A report on the database classification state can be exported or printed to share for compliance and auditing purposes.

  • SQL 脆弱性評価で推奨される機密データの状態を継続的に監視します。Continuously monitor the status of recommended sensitive data in SQL Vulnerability Assessment. 機密データの検出規則を追跡し、分類のための推奨列にドリフトがないか特定します。Track the sensitive data discovery rule and identify any drift in the recommended columns for classification.

  • 組織の特定のニーズに合った方法で分類を使用します。Use classification in a way that is tailored to the specific needs of your organization. Azure Security Center の SQL Information Protection ポリシーで Information Protection ポリシー (機密ラベル、情報の種類、検出ロジック) をカスタマイズします。Customize your Information Protection policy (sensitivity labels, information types, discovery logic) in the SQL Information Protection policy in Azure Security Center.

機密データへのアクセスを追跡するTrack access to sensitive data

機密データにアクセスするユーザーを監視し、監査ログで機密データに対するクエリをキャプチャします。Monitor who accesses sensitive data and capture queries on sensitive data in audit logs.

実装方法:How to implement:

ベスト プラクティス:Best practices:

セキュリティとコンプライアンスの状態を視覚化するVisualize security and compliance status

データ センター (SQL Database のデータベースを含む) のセキュリティ体制を強化する、統一されたインフラストラクチャ セキュリティ管理システムを使用します。Use a unified infrastructure security management system that strengthens the security posture of your data centers (including databases in SQL Database). データベースとコンプライアンス状態のセキュリティに関連する推奨事項の一覧を表示します。View a list of recommendations concerning the security of your databases and compliance status.

実装方法:How to implement:

  • Azure Security Center で、SQL に関連したセキュリティの推奨事項とアクティブな脅威を監視します。Monitor SQL-related security recommendations and active threats in Azure Security Center.

一般的なセキュリティ上の脅威と考えられる軽減策Common security threats and potential mitigations

このセクションは、特定の攻撃ベクトルから保護するためのセキュリティ対策を見つけるのに役立ちます。This section helps you find security measures to protect against certain attack vectors. 多くの軽減策は、前述の 1 つ以上のセキュリティ ガイドラインに従うことによって実現できます。It's expected that most mitigations can be achieved by following one or more of the security guidelines above.

セキュリティの脅威:データ窃盗Security threat: Data exfiltration

データ窃盗とは、コンピューターやサーバーからの許可されていないデータのコピー、転送、または取得です。Data exfiltration is the unauthorized copying, transfer, or retrieval of data from a computer or server. Wikipedia にある「データ窃盗」の定義を参照してください。See a definition for data exfiltration on Wikipedia.

パブリック エンドポイント経由でサーバーに接続するとデータ窃盗のリスクが生じます。これは、ユーザーがパブリック IP に対してファイアウォールを開く必要があるからです。Connecting to server over a public endpoint presents a data exfiltration risk as it requires customers open their firewalls to public IPs.

シナリオ 1: Azure VM 上のアプリケーションが Azure SQL Database 内のデータベースに接続します。Scenario 1: An application on an Azure VM connects to a database in Azure SQL Database. 悪意のあるアクターが VM にアクセスして、不正に侵入します。A rogue actor gets access to the VM and compromises it. このシナリオにおけるデータ窃盗とは、承認されていない VM を使用する外部エンティティがデータベースに接続し、個人データをコピーし、それを BLOB ストレージや、別のサブスクリプションの別の SQL データベースに格納することを意味します。In this scenario, data exfiltration means that an external entity using the rogue VM connects to the database, copies personal data, and stores it in a blob storage or a different SQL Database in a different subscription.

シナリオ 2: 悪意のある DBA。Scenario 2: A Rouge DBA. このシナリオは、規制対象業界のセキュリティに敏感なお客様によって提起されます。This scenario is often raised by security sensitive customers from regulated industries. このシナリオでは、高い特権を持つユーザーが、Azure SQL Database から、データ所有者によって制御されていない別のサブスクリプションにデータをコピーする可能性があります。In this scenario, a high privilege user might copy data from Azure SQL Database to another subscription not controlled by the data owner.

考えられる軽減策:Potential mitigations:

現在、Azure SQL Database および SQL Managed Instance では、データ窃盗の脅威を軽減するために次の方法が提供されています。Today, Azure SQL Database and SQL Managed Instance offers the following techniques for mitigating data exfiltration threats:

  • Azure VM の NSG で許可と拒否の規則を組み合わせて使用して、VM からアクセスできるリージョンを制御します。Use a combination of Allow and Deny rules on the NSGs of Azure VMs to control which regions can be accessed from the VM.
  • SQL Database のサーバーを使用する場合は、次のオプションを設定します。If using a server in SQL Database, set the following options:
    • [Azure サービスを許可する] を [オフ]。Allow Azure Services to OFF.
    • VNet ファイアウォール規則を設定して、Azure VM を含むサブネットからのトラフィックのみを許可します。Only allow traffic from the subnet containing your Azure VM by setting up a VNet Firewall rule.
    • Private Link を使用します。Use Private Link
  • SQL Managed Instance の場合、既定でプライベート IP アクセスを使用することで、承認されていない VM によるデータ窃盗の最大の懸念に対応します。For SQL Managed Instance, using private IP access by default addresses the first data exfiltration concern of a rogue VM. SQL Managed Instance のサブネットに最も制限の厳しいポリシーを自動的に設定するサブネットの委任機能をサブネットで有効にします。Turn on the subnet delegation feature on a subnet to automatically set the most restrictive policy on a SQL Managed Instance subnet.
  • 悪意のある DBA の懸念は、SQL Managed Instance で、より顕在化します。これは、攻撃対象領域が広くなり、ネットワーク要件がユーザーにとって明白だからです。The Rogue DBA concern is more exposed with SQL Managed Instance as it has a larger surface area and networking requirements are visible to customers. これに対する最善の軽減策は、このセキュリティ ガイドに記載されているすべてのプラクティスを適用して、(データ窃盗のためだけでなく) 最初の段階で、悪意のある DBA のシナリオを防止することです。The best mitigation for this is applying all of the practices in this security guide to prevent the Rogue DBA scenario in the first place (not only for data exfiltration). Always Encrypted は、機密データを暗号化して、DBA がキーにアクセスできないようにして保護する 1 つの方法です。Always Encrypted is one method to protect sensitive data by encrypting it and keeping the key inaccessible for the DBA.

ビジネス継続性と可用性のセキュリティ面Security aspects of business continuity and availability

多くのセキュリティ標準では、冗長性とフェールオーバーの機能を実装して単一障害点を回避することで実現される運用の継続性の観点からデータの可用性に対処しています。Most security standards address data availability in terms of operational continuity, achieved by implementing redundancy and fail-over capabilities to avoid single points of failure. 災害シナリオでは、データおよびログ ファイルのバックアップを保持するのが一般的な方法です。For disaster scenarios, it's a common practice to keep backups of Data and Log files. 次のセクションでは、Azure に組み込まれている機能の概要を説明します。 The following section provides a high-level overview of the capabilities that are built-into Azure. また、特定のニーズに合わせて構成できるその他のオプションについても説明します。It also provides additional options that can be configured to meet specific needs:

次のステップNext steps