Amazon RDS for SQL Server でデータを保護: ベストプラクティスと強化のガイダンス

クラウド内の SQL Server データベースを保護することは重要であり、Amazon Relational Database Service for SQL Server (Amazon RDS) は、データベースインスタンスの機密性、整合性、可用性を確保するために役立ついくつかのセキュリティ機能を提供します。これらの機能には、保存中および転送中のデータ暗号化、安全なユーザー認証および認可メカニズム、ネットワーク分離、およびきめ細かいアクセス制御が含まれます。

この投稿では、Amazon RDS for SQL Server インスタンスのセキュリティ体制を強化するためのベストプラクティスを示します。

クラウドセキュリティの概要

クラウドセキュリティの 3 つの主な要素は認証、認可、監査であり、次の図に示すプロセスにさらに分類できます。

プロセスは次のとおりです。

ネットワークセキュリティ – ネットワークセキュリティには、基盤となるインフラストラクチャを不正なアクセスや脅威から保護し、許可されたアクセスのみを許可するようにインフラストラクチャを保護することが含まれます。 Amazon Virtual Private Cloud (Amazon VPC) は、選択した仮想ネットワークで AWS リソースを起動できる、AWS クラウドの論理的に分離されたセクションを提供します。これにより、ネットワークアクセス、ネットワーク分離、ネットワークトラフィックフローなど、AWS インフラストラクチャのセキュリティとネットワーク構成を制御できます。
DB 認証 – これは、データベースにアクセスしようとするユーザーまたはシステムを認証するプロセスです。これは重要なデータへの安全なアクセスを確保するために、ログインとパスワードの認証、多要素認証、証明書ベースの認証などのさまざまな方法を使用して実現できます。
DB 認可 – これは、ユーザーまたはシステムの ID が認証された後に、そのユーザーまたはシステムにアクセス権を付与するプロセスです。これにはデータの読み取りや書き込み、特定のデータベースオブジェクトへのアクセスなど、特定のタスクを実行する権限の付与が含まれる場合があります。これによってデータが安全で許可された個人とシステムのみがデータにアクセスできることが保証されます。
DB アクセス監査 – このプロセスはアカウンティングとも呼ばれ、不正アクセス試行などのセキュリティ問題を検出し、規制およびコンプライアンスの義務を果たすためにデータベースアクティビティの監視と記録を保証します。これはデータベースイベントを監視し、警告を設定し、ログを分析して不審な動作を検出することで実現され、データベースのアクセスと変更に対する監査可能な証跡が得られます。
DB 暗号化 – これは転送中と保存中のデータを暗号化することで、データベースに含まれる機密データへの不要なアクセスを防ぐプロセスです。データベース内の機密データを保護するために、AWS はサーバー側の暗号化、クライアント側の暗号化、スナップショット暗号化などのさまざまな暗号化ソリューションを提供しています。これにより、データベースに不正なアクセスがあった場合でも、暗号化されたデータは安全に保たれ、読み取ることができなくなります。
DB セキュリティ監視 – これにはセキュリティ問題をタイムリーに検知して対応するために、データベースとデータベースが動作するシステムとネットワークのセキュリティを監視することが含まれます。これはデータベースイベントを監視し、セキュリティアラームを設定し、セキュリティ分析ツールを使用してセキュリティリスクを検出して対応することによって実現できます。

次のセクションでは、各コンポーネントについて詳しく説明します。

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

ネットワークセキュリティは、データベースインスタンスを不正アクセスから保護するための重要な手順です。データベースへのすべてのネットワークトラフィックが、ネットワーク構成で明示的に許可されている既知のソースから発信されていることを確認することが重要です。これは主にセキュリティグループとネットワークアクセスコントロールリスト (ACL) を使用して構成できます。

セキュリティグループ

各 RDS for SQL Server インスタンスは 1 つ以上のセキュリティグループに関連付けられます。これらのセキュリティグループを使用すると、インスタンスへのトラフィックを許可する IP または IP アドレスの範囲、およびポートまたはポート範囲を指定して、データベースインスタンスへのトラフィックを制御できます。

セキュリティグループが最大限に活用されるようにするには、データベースへのアクセスが必要な特定のソースおよびポート番号または範囲に対するイングレスルールを必ず追加してください。セキュリティグループは本質的にステートフルであり、受信ルールを通じて許可されている受信トラフィックに対して送信のトラフィックを自動的に許可します。

ネットワークアクセスコントロールリスト (ネットワーク ACL)

ネットワーク ACL を使用すると、VPC 内のネットワークトラフィックをきめ細かく制御できます。ネットワーク ACL ルールはステートレスであるため、受信ルールと送信ルールを個別に指定する必要があります。これらは、VPC 内でデータベースを確実に分離するために追加のポリシーを導入する必要がある場合に役立ちます。

VPC 内のプライベートサブネットに Amazon RDS for SQL Server インスタンスを作成し、ネットワーク ACL を作成して Amazon RDS for SQL Server サブネットに関連付けることで、VPC 内の特定のサブネットからの特定のトラフィックのみが Amazon RDS for SQL Server VPC に到達できるようにすることができます。セキュリティグループとは異なり、ネットワーク ACL はステートレスであり、受信トラフィックと送信トラフィックの両方に対してルールを定義する必要があることを覚えておくことが重要です。ネットワーク ACL を使用している場合、Amazon RDS for SQL Server マルチ AZ インスタンスを構成する場合は UDP と TCP のポート 3343 でのトラフィックを必ず許可してください。

ネットワーク ACL を使用すると、サブネットレベルでトラフィックフローを制御できますが、管理と構成が複雑になる可能性があることに注意することが重要です。そのため、定義されたソースからのトラフィックを許可する必要があってサブネットレベルで管理する必要がない場合は、セキュリティグループの方がこれらのルールを定義する方が適しています。セキュリティグループはインスタンスレベルで動作し、ネットワーク ACL はサブネットレベルで動作するからです。

Amazon RDS for SQL Server データベースインスタンスへのリモート接続

SQL Server Management Studio や他の SQL クライアントなどのツールを使用して、Amazon RDS for SQL Server にリモートで接続する方法は複数あります。ただし、アクセスを容易にしながらリモート接続の安全性を確保することが重要です。セキュリティやコスト削減などのさまざまな理由から、踏み台ホストを使用して接続を Amazon RDS に委任することをお勧めします。

このアプローチでは、踏み台ホストをデプロイして、AWS Systems Manager から Amazon RDS for SQL Server インスタンスへの SQL Server 接続をプロキシします。両方とも VPC 内のプライベートサブネットにデプロイされます。 AWS コマンドラインインターフェイス (AWS CLI) で Systems Manager を使用する手順については、「AWS Systems Manager ユーザーガイド」を参照してください。

次の図は、このアーキテクチャを示しています。

このアプローチは次のように機能します。

適切な API キーを使用して、AWS コマンドラインインターフェイスとセッションマネージャープラグインを備えた VDI/ デスクトップまたはラップトップなどの開発環境を構成します。環境から想定できる SSM 権限を持つ IAM ロールを使用することをお勧めします。
その後、データベースインスタンスがデプロイされているプライベートサブネット内に踏み台ホストまたはジャンプホストをデプロイし、データベースポートへのアクセスを許可するように踏み台ホストのセキュリティグループを構成できます。また、VPC エンドポイントに到達できるように、少なくとも 1 つのルールがアウトバウンド 433 (HTTPS) をカバーしていることを確認してください。
同様に Amazon RDS for SQL Server インスタンスにセキュリティグループを設定して、踏み台ホストのセキュリティグループからの受信トラフィックを許可します。
アクセス許可ポリシー SSMManatedInstanceCore を使用してインスタンスプロファイルを作成し、踏み台ホストに割り当てます。
ローカルワークステーションまたは VDI が適切な IAM ユーザーで構成されていることを確認するか、SSM 権限を持つ IAM ロールを引き受けます。

コマンドプロンプトを開き、次の AWS CLI コマンドを入力します。

aws ssm start-session `
--region <region> `
--target <bastion instance id> `
--document-name AWS-StartPortForwardingSessionToRemoteHost `
--parameters host="<rds endpoint>",portNumber="1433",localPortNumber="1433"

次のようなメッセージが表示されるはずです。

Starting session with SessionId: 12a3456bcdefghi789
Port 1433 opened for sessionId 12a3456bcdefghi789.
Waiting for connections...

これで、SQL Server Management Studio を開いてサーバー名 127.0.0.1,1433 に接続できるようになりました。これにより、踏み台ホストを介して Amazon RDS for SQL Server インスタンスに接続が転送されます。適切な証明書を使用して SSMS を構成し、接続プロパティタブの [接続の暗号化] チェックボックスをオンにして、接続が暗号化されていることを確認します。

この図は Linux の踏み台インスタンスを示していますが、Windows インスタンスも同様に動作するため、Linux ホストである必要はありません。ただし、踏み台ホストがプロキシとして機能し、RDS インスタンスへの接続を通過させるためだけに存在することを考えると、コンピューティングリソースは最もコスト効率の高いオプションに基づく必要があります。

これは、次の理由からRDS for SQL Server インスタンスへのリモートアクセスを有効にする場合のベストプラクティスです。

開く必要があるポートは、踏み台ホストと RDS for SQL Server インスタンスの間のみです。
リモートデスクトップ SSH 接続のために IP 許可リストは必要ありません。
Amazon Elastic Compute Cloud (Amazon EC2) 踏み台ホストは、インターネットに公開せずにプライベートサブネット内に配置できます。
VDI と AWS 環境間の接続には、AWS Direct Connect または AWS VPN を使用することを推奨します。Amazon EC2、Amazon RDS、および Systems Manager はすべて AWS PrivateLink を介して接続が行われるため、インターネットからのアクセスが制限されています。

これまでに説明した方法はネットワークセキュリティに役立ち、選択したトラフィックのみがデータベースに到達できるようにします。ただし、利用可能なさまざまな認証および承認方法を使用してデータベースレベルで RDS for SQL Server インスタンスをさらに保護するだけでなく、データベースに関連する重要なイベントが監視、記録され、さらなる分析や調査に利用できるように監視と監査を実施することも同様に重要です。次のセクションでは、データベースセキュリティのこれらの主要なコンポーネントについて説明します。

データベース認証

SQL または Windows 認証を使用して、RDS for SQL Server データベースに接続できます。 Windows 認証に NTLM または Kerberos を使用することもできます。

SQL Server 認証

SQL Server 内では、SQL Server 認証によってユーザー名とパスワードのペアが追跡されます。 Active Directory (AD) のメンバーではない場合に Amazon RDS for SQL Server に接続する唯一の方法は、SQL Server 認証を使用することです。 SQL Server ログインは、使用時に暗号化されたパスワードと SQL Server ログイン名がネットワーク経由で送信され、ユーザー情報が盗まれる可能性が高くなるため、プライバシーが下がります。したがって、可能な限り SQL Server 認証ではなく Windows 認証を使用してください。

Windows 認証

RDS for SQL Server インスタンスが AWS Managed Microsoft AD の AD ドメインにドメイン参加している場合は、Windows 認証を有効にすることができます。 Windows 認証を有効にすると、AD ドメインユーザーは Windows 資格情報を使用して SQL Server データベースにアクセスできるようになります。ユースケースによっては、これは、特に人間のユーザーが管理や手動クエリの実行のためにアクセスを必要とする場合、データベースへのアクセスを管理するための好ましい方法となる場合があります。
注意： 2023 年 7 月 10 日よりセルフマネージド型の Active Directory をサポートされるようになりました。詳細は、こちらのブログを参照してください。

ドメインユーザーが RDS for SQL Server インスタンスにログインできるようにするには、インスタンスが AD ドメインにドメイン参加していることを確認し、次のクエリを実行してドメインユーザーのログインを作成します。

USE [master] 
GO
CREATE LOGIN [mydomain\myuser] FROM WINDOWS WITH DEFAULT_DATABASE = [master], DEFAULT_LANGUAGE = [us_english]; 
GO

ログインが作成されると、ユーザーはドメイン資格情報を使用してデータベースにアクセスできるようになります。適切なロールがユーザーに追加されていることを確認してください。次のセクションでは、最小権限に基づいてロールを割り当てるベストプラクティスについて説明します。

チームのすべてのメンバーがデータベースにアクセスする必要があるアプリケーションチームなど、複数のユーザーがデータベースにアクセスする必要がある場合があります。このような場合、すべてのユーザーで構成される AD セキュリティグループを作成し、AD グループ全体を RDS for SQL Server インスタンスに追加できます。このアプローチでは、AD グループにユーザーを追加または削除することで、データベースへのアクセスをディレクトリレベルで直接管理できます。

次の図は、このアーキテクチャを示しています。

Windows オペレーティングシステムでは、NTLM と Kerberos という 2 つの一般的なクライアント / サーバー認証方法があります。ただし、次の理由から NTLM よりも Kerberos の方が推奨されます。

チケット発行サービス、キー管理機能の 2 つのパートから構成されています。
暗号化を使用してネットワーク上でパスワードをキャッシュしたり転送したりしないためセキュリティが向上します。
Kerberos には、MiTM (中間者) 攻撃やリプレイ攻撃に対する保護機能が組み込まれています。
Kerberos により相互認証が可能になり、一部の傍受攻撃や不正アクセスを防ぐことができます。

Kerberos がユーザーの認証に失敗した場合、エンドポイントが登録された SPN (サービスプリンシパル名) ではない場合、システムは NTLM にフォールバックします。エンドポイントが登録された SPN である場合は、NTLM にフェイルバックせず失敗します。

次の表は、接続タイプをまとめたものです。

Connection Type	SQL Server Connection String	Login Type	Auth_Scheme
RDS Endpoint	TestSQL.xxxxx.us-east-1.rds.amazon.com	Windows Authentication	NTLM
RDS Fully qualified domain name (FQDN)	TestSQL.octank.com	Windows Authentication	Kerberos
RDS Endpoint	TestSQL.xxxxx.us-east-1.rds.amazon.com	SQL Authentication	SQL
RDS Fully qualified domain name (FQDN)	TestSQL.octank.com	SQL Authentication	SQL

注意 : Always On の可用性グループリスナーは、Kerberos 認証をサポートしていません。

データベース認可

データベース認可に関しては、ロールと権限を使用してデータベースデータへの認可アクセスをユーザーレベルで制限する方法に焦点を当てています。

アプリケーション内でマスターユーザーを直接使用しないことを強くお勧めします。代わりに、アプリケーションに必要な最低限のアクセス権を持つデータベースユーザーを作成するベストプラクティスを採用してください。そうすることで個別のユーザーアカウントを作成することになり、各ユーザーには職務の義務を遂行するために必要な権限のみが付与されます。ロールベースのアクセス (RBAC) 制約を採用して、常に最小特権セキュリティを使用してください。 RBAC は一般にユーザーにデータベースへの読み取り専用アクセスを与えることで、最小限の権限を強制するために使用されます。

Amazon RDS を使用すると、ライフサイクル全体を通じてマスターユーザー認証情報を AWS Secrets Manger に保存および管理できます。 AWS Secrets Manager では 4 時間ごとにシークレットをローテーションできると同時に、同じマネージドローテーションエクスペリエンスを提供できます。

以下は Secrets Manager にパスワードを保存することで得られるメリットの一部です。

RDS はアプリケーションの変更を必要とせずにデータベースの認証情報を定期的にローテーションします。
Secrets Manager は人間のアクセスやプレーンテキストビューからデータベースの資格情報を保護します。
AWS CloudTrail と Amazon CloudWatch を使用するとデータベースの認証情報を簡単に監視できます。
Secrets Manager を使用すると IAM を使用してシークレット内のデータベース認証情報へのアクセスをきめ細かく制御できます。

プライマリユーザーの権限を誤って消去した場合は、データベースインスタンスを更新して新しいプライマリユーザーのパスワードを入力することで権限を復元することができます。また、データベースインスタンスの作成後はプライマリユーザー名を変更できないことにも注意してください。

データベースアクセス監査

データベースを監査する場合は、SQL Server Trace または SQL Server Audit を有効にすることで実行できます。

SQL Server Trace

RDS for SQL Server インスタンスには、その上で実行される T-SQL を利用するデフォルトのサーバー側トレースがあり、システムの現在の実行トレースを提供するカタログビュー sys.traces を介してアクセスできます。ディレクトリ D:\rdsdbdata がサーバー側のトレースのログなどのデフォルトの格納場所になっている事が重要です。 fn_trace_gettable 関数を使用してトレースファイルを読み取ることができます。サーバー側のトレース結果をデータベーステーブルに保存することもできます。次のコードを参照してください。

SELECT * INTO RDSTrace
FROM fn_trace_gettable('D:\rdsdbdata\Log\, default);

このテーブルは任意のユーザーデータベースに対して作成でき、すべてのロールオーバーファイルを含むログディレクトリ内のすべてのファイルの結果がロードされます。 Amazon RDS はデフォルトで、7 日より古いトレースファイルとダンプファイルを削除します。ただし、rds_set_configuration ストアドメソッドを使用すると、トレースファイルの保存期間を変更できます。たとえば、次のストアドプロシージャは、トレースファイルの保持時間を 24 時間 (1440 分) に変更します。

exec rdsadmin..rds_set_configuration 'tracefile retention', 1440;

SQL Server Audit

RDS for SQL Server インスタンスまたは単一データベースを監査するには、データベースエンジンで発生するイベントの追跡とレポートが必要になります。ネイティブな SQL Server Audit を使用すると、サーバーレベルのイベントのサーバー監査仕様と、データベースレベルのイベントのデータベース監査仕様を含めることができるサーバー監査を設計できます。監査されたイベントは常に監査ファイルに記録されます。

オプショングループを使用すると、RDS for SQL Server インスタンスで監査を有効にすることができます。 Amazon RDS ではデフォルトのオプショングループを変更できないため、新しいオプショングループを作成して sqladuit のオプションを追加する必要があることに注意してください。

これらの監査ファイルが削除され、Amazon Simple Storage Service (Amazon S3) に移行される前に、それらをディスク上に保持するオプションが提供されます。監査ファイルはアカウントの S3 バケットに保存されます。監査ファイルは Amazon S3 に保存される前に圧縮されるため、Amazon S3 のコスト削減に役立ちます。 IAM ロールを定義することは、バケットにファイルを書き込む権限を Amazon RDS に付与するため重要です。

これは FedRAMP および HIPAA 監査用に予約されている名前領域であるため、監査ファイルは RDS_ で始まるべきではありません。

ファイルサイズは 2 ～ 50 MB の制限範囲内にすることをお勧めします。そうしないと、これらのファイルの Amazon S3 へのコピーが影響を受ける可能性があります。 AWS は、指定された保存期間の監査ログを保存してアーカイブします。デフォルトでは保持オプションは無効になっており、指定された S3 バケットに監査ログがオフロードされると AWS が監査ログを削除します。この動作は 1 ～ 840 時間の間で任意の値を設定することで変更できます。

ストアドプロシージャ rds_fn_get_audit_file を使用して、SQL Server のサーバー監査によって作成された監査ファイルから情報を取得します。監査が失敗した場合は、 シャットダウンせずに続行するか、操作を失敗するか、のオプションを選択できます。

サーバーレベルの監査は、SQL Server のすべてのエディションでサポートされています。 SQL Server 2016 (13.x) SP1 では、すべてのバージョンでデータベースレベルの監査が可能です。以前は、データベースレベルの監査は Enterprise、Developer、および Evaluation エディションでのみ利用可能でした。

Amazon RDS for SQL Server は、データベースアクティビティストリームをサポートするようになりました。これにより、リレーショナルデータベースでのログインの失敗などのデータベースアクティビティのほぼリアルタイムのストリームを確認できるようになります。詳細については、「データベースアクティビティストリームを使用した Amazon RDS for SQL Server の監査」を参照してください。

データベースの暗号化

このセクションでは、転送中のデータ暗号化、保存時の暗号化、および透過的データ暗号化 (TDE) について説明します。

転送中のデータ暗号化

Secure Sockets Layer (SSL) を使用して、クライアントアプリと SQL Server を実行している RDS データベースインスタンス間の通信を暗号化できます。これを実現するには、パラメータグループを通じて rds.force_ssl パラメータを有効にします。デフォルトでは、rds.force_ssl パラメータは 0 (オフ) に設定されています。接続で SSL の使用を強制するには、rds.force_ssl パラメータを 1 (オン) に設定します。 rds.force_ssl パラメータは静的であるため、値を変更した後に変更を有効にするためにデータベースインスタンスを再起動する必要があります。 SSL/TLS 接続は、クライアントとデータベースインスタンス間で送信されるデータを暗号化することにより、セキュリティ層を追加します。 RDS データベースインスタンスへの接続が確立されていることを確認することで、サーバー証明書によって保護のレベルがさらに高まります。これは、作成したすべてのデータベースインスタンスに自動的に展開されるサーバー証明書を検査することで実現されます。

SSL を使用して、次の 2 つの方法で RDS for SQL Server データベースインスタンスに接続できます。

すべての接続に SSL を強制する – これはクライアントには目に見えずに行われ、クライアントは利用するために何もする必要がありません。
個別の接続を SSL 暗号化する – これにより、特定のクライアントコンピューターからの SSL 接続が確立され、接続の暗号化にはクライアント側での作業が必要になります。

次のコマンドを使用すると、接続が暗号化されているかどうかを確認できます。

select ENCRYPT_OPTION from SYS.DM_EXEC_CONNECTIONS where SESSION_ID = @@SPID

アプリケーションサーバー上で実行されている SQL クライアントからの接続を暗号化するには、接続文字列に encrypt=true を追加します。 JDBC 経由で接続するクライアントに SSL 暗号化を許可するには、Amazon RDS for SQL Server 証明書を Java CA 証明書 (cacerts) リポジトリに追加する必要がある場合があります。これは keytool ユーティリティを使用して可能です。証明書のダウンロードの詳細については、「SSL/TLS を使用した DB インスタンスへの接続の暗号化」を参照してください。

保存時のデータ暗号化

保存時の暗号化を有効にする場合は 2 つの選択肢があります。

AWS Key Management Service (AWS KMS) 暗号化キーを使用して保存時の暗号化を設定します。
SQL Server 2019 Enterprise Edition または Standard Edition を実行している場合は、透過的データ暗号化 (TDE) を利用します。 SQL Server 2019 より前は、TDE 機能は Enterprise エディションでのみ利用可能であったことに注意してください。

データベースインスタンスの作成中に、保存データの暗号化を許可するように AWS KMS を設定できます。暗号化されたデータベースインスタンスを作成するときは、クライアント制御のキーまたは Amazon RDS の AWS 管理のキーのいずれかを使用して暗号化できます。カスタマー管理キーのキー識別子を指定しない場合、Amazon RDS は AWS 管理キーを使用して新しいデータベースインスタンスを作成します。 Amazon RDS は、AWS アカウントの Amazon RDS 管理キーを生成します。 AWS アカウントには、リージョンごとに Amazon RDS 用の一意の AWS 管理キーがあります。

暗号化されたデータベースインスタンスで使用される AWS KMS キーは、構築後に変更することはできません。したがって、暗号化されたデータベースインスタンスを確立するときは、AWS KMS キーの必要性を必ず特定してください。

AWS KMS は、安全で可用性の高いハードウェアとソフトウェアを組み合わせて、クラウドスケールのキー管理ソリューションを提供します。カスタマー管理キーを構築し、AWS KMS を使用してこれらのカスタマー管理キーの使用方法を管理するポリシーを指定できます。 AWS KMS は CloudTrail をサポートしているため、AWS KMS キーの使用状況を監査してカスタマー管理のキーが正しく利用されていることを確認できます。

Amazon RDS 暗号化データベースインスタンスの制限の詳細については、「Amazon RDS リソースの暗号化」を参照してください。

透過的なデータ暗号化

Amazon RDS では、SQL Server データベースインスタンスを暗号化するための透過的データ暗号化 (TDE) もサポートされています。 TDE を保存時の Amazon RDS 暗号化と組み合わせて使用することもできますが、そうするとデータベースのパフォーマンスに多少の影響が出る可能性があります。暗号化手法ごとに個別のキーが必要です。

TDE は、データをストレージに書き込む前に自動的に暗号化し、ストレージから読み取るときにデータを復号化します。 2 層のキーアーキテクチャで暗号化キーを管理します。データ暗号化キーを保護するために、データベースの主キーから発行された証明書が使用されます。データベース暗号化キーは、ユーザーデータベース上のデータの暗号化と復号化を担当します。 Amazon RDS は、データベースの主キーと TDE 証明書を保存および管理します。

データベースインスタンスが TDE 対応のオプショングループにリンクされていない場合は、2 つのオプションがあります。オプショングループを作成するか、対応するオプショングループを変更することで TDE オプションを追加できます。

暗号化されたデータベースが少なくとも 1 つあるデータベースインスタンス上にデータベースがある場合、暗号化されていないデータベースのパフォーマンスが低下する可能性があります。そのため、暗号化されたデータベースと暗号化されていないデータベースを異なるデータベースインスタンスに保持することをお勧めします。

SQLSERVER BACKUP RESTORE および TRANSPARENT DATA ENCRYPTION オプションをデータベースインスタンスに関連付けられたオプショングループに追加する必要があります。

TDE 証明書は、RDS for SQL Server ストアドプロシージャを使用してバックアップ、復元、および削除できます。 Amazon RDS for SQL Server には、回復されたユーザー TDE 証明書を検査する機能があります。

追加の戦略

次の戦略を使用してデータを保護することもできます。

行レベルのセキュリティ – データベースユーザーのアクセスを自分の部門またはビジネスに関連するデータ行のみに制限する場合は、行レベルセキュリティ (RLS) を使用します。 RLS は、データ行アクセス制御の実装を支援します。 RLS を使用すると、アプリケーションのセキュリティの設計とコーディングが容易になります。これにより、アプリケーション層でアクセス制限メカニズムを維持するという依存関係がなくなります。代わりに、データベースシステムは、これらのアクセス制限を実装するためのプレースホルダーとして機能します。適切なテーブル値フィルター関数とセキュリティポリシーを設定すると、RLS を実装してセキュリティ設計の堅牢性と強度を強化できます。 RLS は、RDS for SQL Server 2016 (13.x) で実装された機能で、2016 SP1 以降からは全てのエディションでサポートされています。
データマスキング – データマスキングは、侵入者がアクセスした場合に役に立たないように機密情報を隠すことを可能にするもう 1 つのデータセキュリティ戦略です。機密データを非特権ユーザーからマスクして保護します。デフォルトでは、データベース所有者は例外です。マスクされたデータは、概念実証またはデータ自体が必要ないその他のユースケースで元のデータを置き換えるために使用されます。繰り返しますが、データマスキングメカニズムはデータベースレベルで実行されるため、アプリケーションは現在のクエリを変更することなく機密データを隠すことができます。利用可能なマスキング形式は多数あります。さまざまな機密データカテゴリの個別のニーズに基づいて形式を選択します。データマスキングは、RDS for SQL Server 2016 (13.x) で実装された機能で、2016 SP1 以降からは全てのエディションでサポートされています。
Always encrypted – このデータ暗号化アプローチは、アプリケーションとデータベースサーバー間のデータ転送中、保存中のデータ、およびデータの使用中の機密情報の保護に役立ちます。プレーンテキストを暗号化形式に変換することで、データベースシステム内で機密データが常に暗号化されて表示されることが保証されます。この方法では、テーブルまたはデータベース全体ではなく、選択した列のみが暗号化されることに注意することが重要です。適切な暗号化手法と暗号化キー (列暗号化キーと列主キー) を使用して列を効果的に暗号化できます。暗号化キーを定期的にローテーションすることで、組織のルールやコンプライアンス法を遵守できます。暗号化された列はかなり多くのスペースを必要とすることに注意してください。この機能は、2016 RDS for SQL Server 2016 (13.x) で実装された機能で、2016 SP1 以降からは全てのエディションでサポートされています。詳細については、「Amazon RDS for SQL Server を使用した Always Encrypted のセットアップ」を参照してください。
SQL Server トリガー – トリガーは、特定の条件が満たされた場合に保存されている一連の命令を実行するオブジェクトです。これらを使用すると、オブジェクトへの不正な更新を回避したり、DML や DDL トリガーを使用して新しいログイン認証情報を作成したり、ログオントリガーを使用して Amazon RDS for SQL Server インスタンスに対する合計接続数を制限したりできます。これらのトリガーを Amazon CloudWatch アラームと組み合わせて使用すると、セキュリティポリシーに違反したときに自動メールを送信できます。
列レベルの暗号化 – このアプローチは、より詳細なレベルでデータを暗号化してすべての列または選択した列に適用できます。列レベルの暗号化を使用すると、列ごとに個別の暗号化キーを指定できます。詳細については、「Amazon RDS for SQL Server での列レベルの暗号化」を参照してください。

データベース監視

CloudWatch を使用すると、環境内の異常なアクティビティを特定してアラートを作成、自動アクションを実行して問題を解決できます。エラーと SQL エージェントのログが CloudWatch Logs に公開されるように、[ログエクスポート] オプションを必ず選択してください。

不正なログインデータや、RDS for SQL Server インスタンスのエラーログに報告されたエラーを CloudWatch に公開できます。 Amazon Simple Notice Service (Amazon SNS) を使用して、CloudWatch ロググループ、パターン、アラームに基づいてエンドユーザーに通知を提供できます。

SQL Server ログの CloudWatch Logs への公開はデフォルトでは有効になっていないことに注意してください。さらに、トレースファイルとダンプファイルの公開はサポートされていません。 SQL Server ログの CloudWatch Logs への公開は、アジアパシフィック (香港) を除くすべてのリージョンでサポートされています (この記事の執筆時点) 。

次の図は、CloudWatch を使用したアーキテクチャの例を示しています。

詳細については、「Amazon RDS for SQL Server のモニタリングとアラートを設定する方法のベストプラクティス」を参照してください。

追加の AWS サービス

次のサービスを使用して、セキュリティフレームワークの構築を支援することもできます。

AWS Trusted Advisor – AWS Trusted Advisor は、セキュリティ専門家によって厳選されたコアセキュリティのベストプラクティスを推奨します。これは、AWS 環境のセキュリティの向上に役立つ可能性があります。たとえば、Trusted Advisor は、RDS セキュリティグループのアクセスリスク、保護されていないアクセスキー、不要な S3 バケットのアクセス許可、ルートアカウントの MFA を特定できます。
Amazon Macie – Amazon Macie は、機械学習とパターンマッチングを採用したフルマネージドのデータセキュリティソリューションで、RDS for SQL Server インスタンス内の機密データの検出と保護を支援します。この手順は、Parquet で圧縮されたデータベースのスナップショットをキャプチャし、Amazon S3 に保存することを目的としています。その後、機密データを検索する Macie タスクを開始できます。その後、Amazon Athena と Amazon QuickSight を使用して機密データを読み取り、分析できます。

まとめ

この投稿では、接続、ネットワーキング、さまざまなセキュリティの選択に関するベストプラクティスを含め、Amazon RDS for SQL Server を適切に使用する方法の包括的な概要を説明しました。提供されたソリューションのレビューに基づいて、データベースに適切なセキュリティ方法を決定できます。 TDE 証明書のローテーションの詳細については、「Amazon RDS for SQL Server での TDE 証明書のローテーション」を参照してください。セキュリティパラメータのカスタマイズの詳細については、「Amazon RDS for SQL Server のセキュリティパラメータのカスタマイズ」を参照してください。

Amazon RDS のセキュリティの詳細については、「Amazon RDS のセキュリティ」を参照してください。

このトピックに関して質問や推奨事項がある場合は、コメントを残してください。

著者について

Suprith Krishnappa C は、アマゾンウェブサービスのプロフェッショナルサービスチームのデータベースコンサルタントです。彼は企業顧客と協力して、データベースプロジェクトに関するテクニカルサポートや顧客ソリューションの設計を提供するほか、既存のデータベースを AWS クラウドに移行して最新化するのを支援しています。

Santhosh Srinivasan は、アマゾンウェブサービスのプロフェッショナルサービスチームに所属するシニアクラウドアプリケーションアーキテクトです。金融サービス業界を中心に、クラウドでの大規模エンタープライズアプリケーションの構築とモダナイゼーションを専門としています。

翻訳はソリューションアーキテクトの Yoshinori Sawada が担当しました。原文はこちらです。

Amazon Web Services ブログ