Amazon RDS で機密データを保護するためのベストプラクティスの適用

このシリーズの最初の投稿では、AWS のデータストアに適用できる一般的なセキュリティの概念とそれに対応する AWS のセキュリティコントロールについて説明しました。これらを使用して、データに関わるセキュリティ体制をより強固にすることができます。この 2 回目の投稿では、こうした概念を Amazon RDS データベースで実装する方法を説明します。

実装例の多くはすべての RDS データベースエンジンに共通していますが、一部は個々のエンジンの種類によって異なる場合があります。このような場合は、MySQL との互換性を持つ Amazon Aurora の実装例を含めますが、他のデータベースエンジンの情報を入手する場所についても説明します。

それでは、最初の投稿で説明した順序でセキュリティの概念の実装を見ていきましょう。

データの分類とセキュリティゾーンモデリング

データの分類とセキュリティゾーンモデリングに関するおさらいとして、以下をご覧ください。ここで提供されているより詳細な説明、およびデータの分類とセキュリティゾーンモデリングの背景にある概念については、このシリーズの最初の投稿を参照してください。

データの分類

この投稿で後述するセキュリティコントロールのどれを適用するかを決定するには、データの分類を理解してください。たとえば、どちらもこの投稿の後半で説明しますが、データのトークン化やセキュリティのマイクロセグメンテーションなど、特殊なセキュリティコントロールは必要ないかもしれません。これらが不要であるケースとしては、データベースにクレジットカード番号や社会保障番号などの機密性の高いデータがない場合があります。

セキュリティゾーンモデリング

セキュリティゾーンを設計したら、ネットワークアクセスコントロールリスト (ACL) を使用して実装します。サブネット全体をネットワークフロー制御バリアとして使用できるようにすることをお勧めします。この投稿の後半の「セキュリティグループとネットワーク ACL」セクションで、ネットワーク ACL を使用してセキュリティゾーンを実装する方法を示します。

セキュリティゾーンモデリングを実装するときは、ネットワーク設計を慎重に検討します。CIDR 範囲のサイズによって、各サブネットが表現できる IP アドレスの数が決まります。サブネット内の増加 (より多い IP アドレス) とサブネット数の増加をサポートできるように、CIDR 範囲を設計します。Amazon VPC とオンプレミスのデータセンター間、または VPC 間に矛盾のない IP アドレススペースを確保するための要件とバランスを取ります。詳細については、AWS Answers サイトの AWS 単一 VPC の設計を参照してください。

徹底的な防御

RDS 内での徹底的な防御のためのセキュリティコントロールの詳しい説明に入る前に、この投稿の後半で説明するセキュリティ設定について説明している RDS 起動ウィザードのセクションを見てみましょう。

セキュリティ設定を取得するには、AWS マネジメントコンソールの RDS に移動します。

[Create Database] を選択します。このブログ投稿の目的から、ここでは Aurora MySQL データベースインスタンスを使います。

それでは、この投稿の後半で説明する RDS セキュリティコントロールの一部として、何を変更するかを見てみましょう。[Step 3 – Configure advanced settings] に到達するまで、起動ウィザードに従います。

このブログ投稿で取り上げているセキュリティコントロールに関係のない他のデフォルトの RDS 設定の変更は、この投稿の範囲外です。Aurora データベースインスタンスを起動するための完全なステップバイステップガイドに従うには、RDS ドキュメントの Amazon Aurora の使用開始を参照してください。他のdatabase データベースエンジンについては、Amazon RDS の使用開始を参照してください。

それでは、防御を構成するセキュリティコントロールについて詳しく説明しましょう。次の図は最初の投稿からのもので、防御の概念を詳しく説明しています。コントロールには、予防的コントロールと発見的コントロールの 2 つの主要なカテゴリーがあります。

予防的コントロール

DDOS 保護

AWS Shield Standard および Advanced と連携することで、アプリケーションおよびデータベースを分散サービス拒否 (DDOS) 攻撃から保護することができます。すべての AWS の顧客は、追加料金なしで AWS Shield Standard による自動保護のメリットを受けることができます。AWS Shield Standard は、ウェブサイトやアプリケーションを標的にした、最も一般的で頻繁に発生するネットワークおよびトランスポートレイヤーの DDoS 攻撃を防御します。AWS Shield Standard を Amazon CloudFront や Amazon Route 53 とともに使用すると、インフラストラクチャ (レイヤー 3 および 4) を標的とするすべての既知の攻撃を総合的に保護できます。

24 時間 365 日の DDoS レスポンスチームへのアクセスを含む高レベルな保護には、AWS Shield Advanced を使用できます。利用可能な追加の保護の詳細については、AWS Shield Advanced の機能ページを参照してください。以下は、AWS Shield Advanced を有効にする手順の例です。

AWS コンソールで、[AWS WAF and AWS Shield] に移動します。AWS WAF または AWS Shield Advanced をまだ有効にしていない場合は、次のページが表示されます。それ以外の場合は、AWS WAF および AWS Shield のダッシュボードページが表示されます。

[AWS Shield] を選択して、Standard と Advanced を比較します。この例では、AWS Shield Advanced を有効にします。

アプリケーションレベルの脅威の防止

アプリケーションレベルの脅威の防止を支援するために、以下で説明するように、AWS WAF とデータベースファイアウォールをお勧めします。

AWS WAF

使用しているウェブアプリケーションは、データベースに保存されているデータにアクセスする必要があるとします。そのため、SQL インジェクションや、その他のウェブアプリケーションに対する OWASP (Open Web Application Security Project) のトップ 10 の最も重要なセキュリティリスクなどのアプリケーションへの攻撃による漏洩からデータを保護することが重要です。(これらのついての詳細情報は、OWASP のサイトを参照してください。) Amazon CloudFront ディストリビューション内で、または Application Load Balancers によって有効にすることで、これらの脅威からアプリケーションを保護するように AWS WAF を設定することができます。

AWS WAF の使用を開始するには、コンソールで [AWS WAF and AWS Shield] に移動します。AWS WAF または AWS Shield Advanced をまだ有効にしていない場合は、次のページが表示されます。それ以外の場合は、AWS WAF および AWS Shield のダッシュボードページが表示されます。

これがアカウントで最初のウェブ ACL である場合は、次のページが表示されます。

それ以外の場合は、次のように新しいウェブ ACL を作成します。

次に、ウェブ ACL を設定します。

AWS WAF のルールを設定するには、まず、アプリケーションレベルの脅威の検出で使用する条件をいくつか作成します。以下は、SQL インジェクションの条件の作成例を示しています。それぞれ複数のフィルターを使用して、複数の条件を作成することができます。

次に、上記の条件を使用する AWS WAF のルールを作成します。

データベースファイアウォール

アプリケーションレベルの攻撃から保護するための追加のアプローチは、AWS パートナーからのデータベースファイアウォールソリューションを実装することです。こうしたソリューションは、AWS Marketplace にあります。

ネットワークの分離

機密データに対するセキュリティ上の重要な考慮事項の 1 つは、データベースのネットワークの分離です。ネットワークを分離すると、データベースはプライベート IP アドレスの一定の範囲でのみ、アクセスを必要とするコンポーネントだけがアクセスできるようになります。このセキュリティの分離を可能にする基本的な設計要素が、Amazon VPC です。データベースインスタンスを作成する時点で、VPC をデータベースインスタンスに関連付けます。

それでは、VPC の作成から始めましょう。AWS コンソールで VPC に移動し、[Create VPC] を選択します。

VPC の名前を選択し、CIDR 範囲を指定します。

次に、RDS データベース専用の VPC サブネットを作成します。VPC ダッシュボードのナビゲーションペインで、[Subnets] を選択してから [Create subnet] を選択します。

サブネットに名前を付けて、CIDR 範囲とアベイラビリティーゾーンを指定します。

AWS リージョン内のそれぞれのアベイラビリティーゾーンに対してこの手順を繰り返します。このブログでの例の AWS リージョン、つまり ap-southeast-2 には、3 つのアベイラビリティーゾーンがあります。したがって、この手順を 3 回繰り返して、それぞれのアベイラビリティーゾーンに 1 つずつ、合計 3 つのサブネットを作成します。AWS リージョン内でのアベイラビリティーゾーンの使用方法の詳細については、Amazon EC2 ドキュメントのリージョンとアベイラビリティーゾーンを参照してください。

次の手順は、以下の例に示すように、データベースのサブネットをサブネットグループと呼ばれる Amazon RDS コンストラクトに追加することです。サブネットグループは、RDS インスタンスがデプロイされるサブネットの集まりです。詳細については、RDS のドキュメントの DB サブネットグループを使うを参照してください。

AWS コンソールで RDS に移動し、[Create DB Subnet Group] を選択して新しいサブネットグループを作成します。

ここで、作成した VPC とサブネットグループをデータベースインスタンスと関連付け、パブリックアクセスについて [No] を選択します。これは、RDS 起動ウィザードの [Network & Security] セクションで行うことができます。

セキュリティグループとネットワーク ACL

以下で説明するように、セキュリティグループとネットワーク ACL もセキュリティにとって重要です。

ネットワーク ACL

ネットワーク ACL を使用してセキュリティゾーンモデリングを実装します (ネットワーク ACL の使用方法の詳細については、VPC のドキュメントのネットワーク ACL を参照してください)。セキュリティゾーンは、類似の信頼レベルのアセットを含む、明確に定義されたネットワーク境界を提供します。セキュリティゾーンはまた、明確さと推論の容易さをもたらし、特性に基づいてセキュリティゾーンに出入りするネットワークフローの制御方法を定義し、実施します。

以下は、セキュリティゾーンモデリングに対する 1 つのアプローチを表す図です。

この図のモデルでは、以前に作成したデータベースのサブネットは論理的にはセキュアゾーンに属しています。それでは、適切なネットワークトラフィック制御を適用するためにネットワーク ACL を作成しましょう。ネットワーク ACL はステートレスなので、インバウンドルールとアウトバウンドルールの両方を明示的に指定する必要があります。次の例に示すように、インバウンドルールとアウトバウンドルールは、データベースコンシューマに属する CIDR 範囲との間で送受信されるトラフィックだけを許可します。例としては、前の図で内部 (プライベート) ゾーンとして示されているアプリケーションレイヤーです。

また、インバウンドトラフィックも、Aurora MySQL 用に設定されたポート (デフォルトでは、ポート 3306) に制限されます。他の RDS データベースの場合は、そのデータベース用に設定されたポートを使用します。

セキュアゾーンサブネットのネットワーク ACL を作成するには、コンソールで VPC に移動して [Network ACL] を選択します。

注意: 他のセキュリティゾーンに属するサブネットについても同様の手順に従います。

注意: MySQL クライアントがデータベースと通信するために使用する一時的なポート範囲のトラフィックを許可するようにネットワーク ACL アウトバウンドルールを設定します。さらに、Microsoft SQL Server 用の Active Directory トラフィックのように、データレプリケーションまたは管理のトラフィック用の追加ポートでのトラフィックを許可するようにルールを設定します。

次の例に示すように、セキュアゾーンネットワーク ACL をデータベースがデプロイされているサブネットに関連付けます。

セキュアゾーンを構成するサブネットは、前述のセキュリティゾーンモデリングの図に示すように、階層化されたセキュリティゾーンモデルの一部です。セキュアゾーンと相互作用する、およびお互いの間でも相互作用するアプリケーションレイヤーをホストする追加のセキュリティゾーンを作成します。アプリケーションレイヤーのセキュリティゾーンは、独自のネットワーク ACL を介してネットワークトラフィックをフィルタリングすることによって、セキュアゾーンをさらに高度に分離します。

セキュリティグループ

データベースのサブネットにネットワーク ACL をすでに定義している場合、なぜデータベースにセキュリティグループが必要になるのでしょうか? セキュリティグループを使用して、階層化されたセキュリティ設計とデータベースのマイクロセグメンテーションを行います。セキュリティグループの操作の詳細については、VPC のドキュメントの VPC のセキュリティグループを参照してください。

アプリケーション層に 2 つのマイクロサービス (前の図の内部 (プライベート) ゾーン) と、データベース層に 2 つの対応するデータベース (セキュアゾーン) があるとします。それぞれのデータベースは、2 つのマイクロサービスのうちの 1 つに関連付けられています。

どちらのマイクロサービスも、ネットワーク ACL を介してデータベーストラフィックをセキュアゾーンに送信します。マイクロサービス 1 がマイクロサービス 2 のデータベースにトラフィックを送信しないようにするにはどうすればよいでしょうか? これを行うには、個々のセキュリティグループを 2 つのデータベースのそれぞれに関連付け、そのデータベースを所有する対応するマイクロサービスからのトラフィックだけを有効にします。次の図は、このマイクロセグメンテーションを示しています。

次の例は、対応するマイクロサービスのセキュリティグループになることができる専用セキュリティグループからの許可されたインバウンドトラフィックだけを設定することによってこれを示しています。開始するには、コンソールで VPC に移動して [Security Groups] を選択します。

RDS データベースインスタンスを起動するときにこのセキュリティグループをアタッチするには、[Network & Security] までスクロールします。データベースインスタンス用に作成したセキュリティグループを選択します。

AWS Identity and Access Management

AWS Identity and Access Management (IAM) は、AWS を基盤とする顧客が利用できる基本的なコントロールです。これは、AWS Well Architected フレームワークのセキュリティの柱の 5 つのベストプラクティスのうちの最初のものです。このフレームワークを使用することで、信頼性があり、安全で、効率的で、費用対効果の高いシステムをクラウドで設計および運用するためのアーキテクチャ上のベストプラクティスを学ぶことができます。

IAM を使い始めるには、コントロールプレーン操作のアクセス要件とデータプレーン操作のアクセス要件を分けます。

コントロールプレーン操作

RDS の場合、コントロールプレーン操作とは、CreateDBInstance、ModifyDBInstance、CreateDBParameterGroup などの RDS インスタンス上の管理機能のことです。これらはより高い特権の操作であるため、関連する特権をユーザーまたはロールに割り当てるときには十分に注意して厳密に行います。

以下は、指定されたデータベースインスタンスに対して限られた一連の管理操作を許可する IAM ポリシーの例です。このポリシーをユーザー、グループ、またはロールにアタッチすることができます。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "LimitedAdmin",
            "Effect": "Allow",
            "Action": [
                "rds:CreateDBSnapshot",
                "rds:StopDBInstance",
                "rds:StartDBInstance"
            ],
            "Resource": [
                "arn:aws:rds:[your_region]:[your_AWS_account_id]:snapshot:*",
                "arn:aws:rds:[your_region]:[your_AWS_account_id]:db:demoDB"
            ]
        },
        {
            "Sid": "DescribeInstances",
            "Effect": "Allow",
            "Action": "rds:DescribeDBInstances",
            "Resource": "*"
        }
    ]
}

データプレーン操作

データプレーン操作とは通常、データベース内のデータを選択、挿入、変更、削除するアクションを指します。Amazon RDS データベースでデータプレーン操作を有効にするには、次の 2 つの部分があります。

データベース認証
データベースアクセスコントロール

まず認証、つまり誰がデータベースへのアクセスを許可されているかです。データベース内で認証を設定できます。あるいは、Amazon Aurora を MySQL または PostgreSQL との互換性または、RDS for MySQL や PostgreSQL とともに使用している場合は、IAM 統合を使用して認証を設定することもできます。

2 つ目の部分はアクセスコントロールです。つまり、データベースユーザーはどのレベルのアクセス権を持っているかということです。アクセスコントロールはデータベース内で定義します。

データベース認証 – まず、データプレーン操作用の認証を設定する方法を見てみましょう。

認証オプション 1 は、IAM データベース認証を使用します。このアプローチを採用するには、新しい RDS データベースインスタンスを起動するときに [Enable IAM DB authentication] を選択します。

マスターアカウントでデータベースインスタンスに接続し、IAM ユーザーまたはロールの IAM 認証と統合するデータベースアカウントを作成します。

mysql --host=[your_AuroraMySQL_cluster_endpoint] --port=3306 --ssl-ca=rds-combined-ca-bundle.pem --user=master -p

CREATE USER [your_db_user] IDENTIFIED WITH AWSAuthenticationPlugin AS 'RDS';

RDS インスタンスへの接続を許可する IAM ポリシーを追加します。この場合、リソースとして Aurora クラスターを選択します。

AWS コンソールで IAM に移動し、ポリシーを選択します。

環境に合わせてポリシー定義を変更します。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "rds-db:connect"
            ],
            "Resource": [
                "arn:aws:rds-db:[your_region]:[your_AWS_account_id]:dbuser:[your_AuroraMySQL_resourceId/[your_db_user]"
            ]
        }
    ]
}

このポリシーの Amazon リソースネーム (ARN) について、定義する必要がある主なコンポーネントを特定しましょう。ARN が「arn:aws:rds-db:ap-southeast-2:1234567890:dbuser:cluster-WIK2GTMJGD5K7F4OJJ2DLCV6CA/db_iam_user」であるとすると、以下が主なコンポーネントです。

ap-southeast-2 は、Aurora MySQL クラスターが作成された AWS リージョン
1234567890 は、AWS アカウント番号
cluster-WIK2GTMJGD5K7F4OJJ2DLCV6CA は、Aurora MySQL クラスターのリソース ID
db_iam_user は、Aurora MySQL で作成したデータベースユーザー

注意: IAM コンソールを使用してポリシーを作成している場合、現在は rds-db:connect アクションのポリシーにエラーが表示されます。このエラーは無視してかまいません。

最後に、前述の IAM ポリシーを IAM ユーザーまたはロールにアタッチします。この例では、IAM ユーザーにポリシーを追加します。

前の手順で作成したポリシーは、rds-connect-policy という名前です。

IAM ポリシーと RDS を使用する作業の詳細な手順については、RDS のドキュメントの IAM データベースアクセス用の IAM ポリシーの作成と使用を参照してください。IAM 認証を使用して RDS に接続する方法のステップバイステップガイドについては、AWS データベースブログの投稿 Amazon Aurora MySQL または Amazon RDS for MySQL に SQL Workbench/J で接続するための IAM 認証の使用を参照してください。

認証オプション 2 は、組み込みのデータベース認証コントロールを使用します。

例として、次のデータベースコマンドは、データベースエンジンによって認証されるユーザーを作成します。

CREATE USER db_user IDENTIFIED BY '<パスワード>';

このアプローチを採用する場合は、データベースパスワードのローテーションとパスワードへのアプリケーションアクセスに AWS Secrets Manager を使用することをお勧めします。AWS Secrets Manager を使用することで、データベースパスワードをアプリケーションコードまたは設定にハードコードする必要がなくなります。また、パスワードローテーションに自動化を適用することもできます。

パスワードのローテーションに AWS Secrets Manager を使用する方法については、AWS セキュリティブログの投稿 Oracle を含むすべてのタイプの Amazon RDS データベースで認証情報をローテーションするために AWS Secrets Manager を使用する方法をご覧ください。AWS Secrets Manager は AWS Lambda 関数を使用して RDS データベースのパスワードをローテーションします。これを行うために Lambda 関数が使用するロジックの詳細については、Lambda のドキュメントの Lambda ローテーション関数の概要を参照してください。

AWS Secrets Manager は、シークレットがローテーションされている RDS データベースと同じ VPC およびサブネットグループに AWS Lambda 関数を作成します。Lambda 関数が作成されたら、それを管理ゾーンのサブネット (前のセキュリティゾーンのモデル図に示されています) に再アタッチします。

データベースアクセスコントロール – ユーザーが認証されると、データベースエンジンは、テーブル、ビュー、ストアドプロシージャなどのデータベースリソースに対するユーザーのアクセスレベルを確認します。データベースにアクセスレベルを設定するには、事前定義されたデータベースロールをユーザに割り当てるか、個々の特権を直接付与します。

以下のコマンドは、データ操作言語 (DML) アクセスをユーザーに付与する方法の例です。これは、ユーザーがアクセスできるデータベースリソースを指定する承認です。これは、ユーザーのアイデンティティを検証する認証とは別のものです。したがって、この承認プロセスは、ユーザーがデータベースによって認証されているか、統合 IAM 認証を使用して認証されているかにかかわらず同じです。

GRANT SELECT, INSERT, DELETE ON demoschema.* TO 'db_user';

暗号化とトークン化

また、以下で説明するように、データベースセキュリティの鍵は暗号化とトークン化です。

休止中の暗号化

休止中の暗号化を有効にすることは重要です。データベースとスナップショットの基盤となるボリューム (暗号化されている場合) は、AWS KMS 暗号化キーのアクセス許可が明示的に付与されている場合にのみ、AWS アカウントの外部で読み取ることができます。

すべての RDS データベースエンジンで休止中の暗号化を有効にするには、RDS データベースインスタンスを作成するときに簡単な構成オプションを設定します。以下は、Aurora MySQL で休止中の暗号化を有効にする方法の例です。RDS インスタンスを作成した後は、休止中の暗号化を有効にできないことに注意してください。したがって、データベースのプロビジョニングプロセスに組み込まれていることを確認する必要があります。

休止中の RDS 暗号化に加えて、特定のデータベースエンジンにネイティブの暗号化機能を有効にすることもできます。例としては、RDS SQL Server および RDS Oracle での Transparent Data Encryption (TDE)、SQL Server の SQL Server 常時暗号化オプションがあります。

以下のように、RDS 起動ウィザードの一部として、休止中の RDS 暗号化を有効にします。

移動中の暗号化

Amazon RDS は、それぞれの RDS データベースに対して SSL (Secure Sockets Layer) 証明書を自動的に作成して、SSL を介したクライアント接続を有効にします。使用している AWS リージョンに固有の RDS SSL 証明書を使用して、アプリケーションが正しい AWS リージョンの RDS インスタンスに接続していることを確認します。RDS ドキュメントの SSL を使用して DB インスタンスへの接続を暗号化するに、個々の AWS リージョンのリージョン中間証明書をダウンロードするリンクがあります。

注意: RDS Oracle データベースの場合、RDS ドキュメントの説明に従って、Oracle SSL オプションをオプショングループに追加する必要があります。

トークン化

トークン化は、機密データを一意の識別子に置き換えます。これらの識別子を使用して、別のデータソースにある元の機密データを見つけます。対照的に、暗号化では機密データに暗号を適用して、許可された関係者だけが読み取ることができるようにデータをエンコードします。

トークン化は、機密性の高いデータや PCI などの特定の規制遵守要件を持つデータの特定の部分を保護するのに役立つ暗号化の代替手段です。機密データを専用の安全なデータストアに分離し、その代わりにトークンを使用することで、エンドツーエンド暗号化の潜在的なコストと複雑さを回避できます。一時的な使い捨てトークンを使用することで、リスクを軽減させることもできます。

トークン化は、アプリケーションレベルの実装上の問題です。通常、トークンとそれに対応する機密データ値の間のマッピングを保持するために専用のデータストアを使用して実装します。トークンは機密データ値の代わりにアプリケーションデータベースに保存され、実行時にアプリケーションによって専用トークンデータストアから実際の値に置き換えられます。

次の図は、トークン化プロセスの例を示しています。

この例の手順は以下のとおりです。

アプリケーションは、クレジットカード番号などの機密データをトークン化 API に提示します。
トークン化 API は、アプリケーションユーザーの認証を要求します。
認証 API が、ユーザーを認証します。
トークン化 API が、クレジットカード番号に対するトークンを生成し、トークンとクレジットカード番号とをトークン化データベースに保存してリンクさせます。
トークン化 API が、トークンをアプリケーションに返します。
アプリケーションは、クレジットカード番号の代わりにトークンをアプリケーションデータベースに保存します。

発見的コントロール

以下で説明する発見的コントロールもデータベースのセキュリティにとって重要です。

不正なトラフィックの発見

VPC フローログや AWS CloudTrail ログをカスタムロジックで監視して異常を特定するなど、不正なトラフィックの発見を実装する方法はいくつかあります。VPC フローログの詳細については、VPC ドキュメントの VPC フローログを参照してください。CloudTrail ログの詳細については、CloudTrail ドキュメントの CloudTrail ログファイルの使用方法を参照してください。

あるいは、Amazon GuardDuty を有効にしてユーザーに代わってネットワークトラフィックを監視させ、機械学習を適用して異常な行動を検出して警告することもできます。アカウントで Amazon GuardDuty を有効にする方法は以下のとおりです。

AWS コンソールで、Amazon GuardDuty に移動します。AWS アカウントで GuardDuty を初めて有効にする場合は、次のページが表示されます。

[Enable GuardDuty] を選択して、GuardDuty をオンにします。

次に、GuardDuty の検出結果を監視して対処する CloudWatch ルールを作成します。Amazon SNS によって通知アラートを設定し、Lambda による自動修復アクションを設定することもできます。

次のスクリーンショットは、SNSトピックとして E メールアラートを送信する、指定された GuardDuty イベントの CloudWatch ルールの例を示しています。

これを設定するには、コンソールで CloudWatch に移動し、[Rules] を選択して新しいルールを作成します。その後、以下の手順を行います。

[Create rule] を選択します。
[Event Pattern] が選択されていることを確認します。
リストから、[Build custom event pattern] を選択します。

以下の JSON をカスタムイベントウィンドウに追加します。

{
  “source”: [
    “aws.guardduty”
  ],
 “detail”: {
   “type”: [
     “UnauthorizedAccess:IAMUser/MaliciousIPCaller.Custom”
     ]
   }
}

[Target] セクションで、[Add target] を選択して CloudWatch ルールの新しいターゲットを追加します。
リストから [SNS topic] を選択し、Amazon SNS トピック名を選択します。

設定のドリフト

設定のドリフトは、システムの現在のセキュリティ設定が理想的な強化状態からずれている状態のことです。設定のドリフトは、最初のデプロイ後にシステムに変更を加えることによって発生する可能性があります。

次の例では、AWS Config を使用してベースライン設定に対してデータベースの設定を継続的に監視し、設定がベースラインから逸脱したときにアラートを送信します。

これを設定するには、コンソールで [AWS Config] に移動し、[Rules] を選択して新しい AWS Config ルールを追加します。

注意: 初めて AWS Config を有効にする場合は、初期セットアッププロセスが実行されることがあります。

その後、以下の手順を行います。

[Add rule] を選択します。
検索ボックスに、「RDS」と入力します。
有効にしたい RDS 設定チェックを選択します。

RDS の事前定義ルールを検索して選択するか、新しいカスタムルールを作成します。

きめ細かい監査

以下に説明するように、データベースのセキュリティを強化するために、さらにきめ細かい監査を実行することができます。

コントロールプレーン操作

前述のように、RDS の場合、コントロールプレーン操作とは、CreateDBInstance、ModifyDBInstance、CreateDBParameterGroup などの RDS インスタンス上の管理機能のことです。すべての Amazon RDS コントロールプレーン操作は CloudTrail によって記録され、Amazon RDS API リファレンスに文書化されています。

CloudTrail で新しい証跡を作成すると、すべての CloudTrail ログを監査目的で Amazon S3 に保存することができます。詳細については、AWS CloudTrail を使用した Amazon RDS API 呼び出しのログ記録を参照してください。

新しい証跡を作成するには、コンソールで CloudTrail に移動して [Trails] を選択します。

次のスクリーンショットは、CloudTrail によって記録されたすべての RDS API 呼び出しに一致し、ユーザー定義の通知またはアクションをトリガーできる Amazon CloudWatch ルールを示しています。このルールを作成するには、以下の手順を実行します。

コンソールで Amazon CloudWatch に移動します。
[Rules] を選択して、新しいルールを作成します。
[Create rule] を選択します。
[Event Pattern] が選択されていることを確認します。
リストから、[Build custom event pattern] を選択します。
[Service Name] については、[Relational Database Service (RDS)] を選択します。
[Event Type] については、[AWS API Call via CloudTrail] を選択します。
[Any operation] を選択します。
[Targets] セクションで、[Add target] を選択して CloudWatch ルールの新しいターゲットを追加します。
リストから [SNS topic] を選択し、Amazon SNS トピック名を選択します。

データプレーン操作

再び、データプレーン操作とは通常、データベース内のデータを選択、挿入、変更、削除するアクションを指します。Aurora MySQL では、Aurora DB クラスターのパラメータグループで高度な監査を有効にすることでデータプレーン操作を追跡できます。データベースパラメータグループは、1 つ以上のデータベースインスタンスに適用されるエンジン設定値のコンテナとして機能します。

以下は、Aurora MySQL で高度な監査を有効にする方法の例です。詳細については、Aurora ドキュメントの Amazon Aurora MySQL DB クラスターでの高度な監査の使用を参照してください。

コンソールで RDS に移動し、[Parameter groups] を選択して新しいパラメータグループを作成します。

Aurora クラスターのカスタムパラメータグループを作成します。

カスタムパラメータグループを変更して、server_audit_logging を有効にします。

カスタムパラメータグループを変更して、CloudWatch へのログのエクスポートを有効にします。CloudWatch Logs を使用すると、カスタムの通知とアクションを作成できるようになります。これを行うには、適切な CloudWatch Logs アクセスロールをクラスターパラメータにアタッチします。詳細情報は、Aurora ドキュメントの Amazon Aurora MySQL ログを Amazon CloudWatch Logs で公開するにあります。

最後に、データベースインスタンスを起動するときに、このカスタムクラスターパラメータグループを Aurora MySQL クラスターに関連付けます。

他の RDS データベースエンジンで詳細な監査ログを有効にする方法の詳細については、以下のドキュメントトピックを参照してください。

RDS Oracle について Oracle 監査ファイル
RDS PostgreSQL について PostgreSQL の監査ロギング
RDS MariaDB について RDS MySQL の Maria db 監査プラグイン

スイムレーンの隔離

スイムレーンの隔離の説明と概念的概要については、このシリーズの最初の投稿を参照してください。スイムレーンの隔離を実装して、さまざまなビジネスドメインのデータベースやアプリケーションの間でサブネットレベルの厳密な分離を実現します。スイムレーンの隔離を実装するには、前述したようにセキュリティグループとネットワーク ACL でネットワーク ACL を使用します。

まとめ

この投稿では、このブログシリーズの最初の投稿で説明した一般的なデータセキュリティパターンを RDS データベースに適用する方法について説明しました。これを実行すると、機密データに関して強力なセキュリティ体制を構築するのに役立ちます。

また、この投稿では、階層型アプローチを使用して RDS データベースを保護する方法についても詳しく説明しました。このアプローチでは、VPC 内のネットワーク ACL とサブネットを使用するネットワークセキュリティゾーンを使用します。

さらに、AWS ネットワーキング、IAM、およびデータベースサービス内で AWS の予防的なセキュリティコントロールの組み合わせを有効にする方法についても説明しました。データの徹底的な防御を可能にするために、Amazon GuardDuty、AWS Config、AWS CloudTrail を使用して発見的コントロールを設定する方法について取り上げました。

このシリーズの次回と最後の投稿では、同じセキュリティの概念を Amazon DynamoDB に適用する方法を示します。

著者について

Syed Jaffry は、アマゾンウェブサービスのソリューションアーキテクトです。彼は、金融サービス業界の顧客と協力して、安全で回復力があり、スケーラブルで高性能なアプリケーションをクラウドに展開するのを支援しています。

Amazon Web Services ブログ

Amazon RDS で機密データを保護するためのベストプラクティスの適用

データの分類とセキュリティゾーンモデリング

データの分類

セキュリティゾーンモデリング

徹底的な防御

予防的コントロール

DDOS 保護

アプリケーションレベルの脅威の防止

AWS WAF

データベースファイアウォール

ネットワークの分離

セキュリティグループとネットワーク ACL

ネットワーク ACL

セキュリティグループ

AWS Identity and Access Management

コントロールプレーン操作

データプレーン操作

暗号化とトークン化

休止中の暗号化

移動中の暗号化

トークン化

発見的コントロール

不正なトラフィックの発見

設定のドリフト

きめ細かい監査

コントロールプレーン操作

データプレーン操作

スイムレーンの隔離

まとめ

著者について

お役立ちリンク

フォローお願いいたします