データベース監査ログ作成

Amazon Redshift は、データベースの接続とユーザーアクティビティに関する情報を記録します。これらのログは、セキュリティとトラブルシューティング目的でのデータベースのモニタリングに役立ちます。このプロセスは、データベース監査と呼ばれます。ログは次の場所に保存できます。

Amazon Redshift ログ

Amazon Redshift は、次のログファイルに情報を記録します。

接続ログとユーザーログは、主にセキュリティに役立ちます。接続ログを使用して、データベースに接続するユーザーや関連する接続情報についての情報をモニタリングできます。この情報には、ユーザーの IP アドレス、要求日時、使用した認証の種類などが含まれます。ユーザーログを使用して、データベースユーザーの定義の変更を監視できます。

ユーザーアクティビティログは、主にトラブルシューティングに役立ちます。ユーザーとシステムによってデータベースで実行されるクエリの種類についての情報を追跡します。

接続ログとユーザーログは、データベースのシステムテーブルに保存されている情報と一致します。システムテーブルを使用して同じ情報を取得できますが、ログファイルのほうがより簡単に検索と参照ができます。ログファイルは、テーブルに対してクエリを実行するために、データベースのアクセス許可ではなく Amazon S3 のアクセス許可に依存しています。また、システムテーブルに対してクエリを実行するのではなくログファイルの情報を参照するので、データベースとのやりとりによる影響が軽減されます。

接続ログ

認証の試行、接続と切断を記録します。次の表は、接続ログの情報を示しています。これらのフィールドの詳細については、Amazon Redshift データベースデベロッパーガイドの「STL_CONNECTION_LOG」を参照してください。Amazon Redshift Serverless で収集した接続ログデータの詳細については、「SYS_CONNECTION_LOG」を参照してください。

ユーザーログ

データベースユーザーに対する次の変更の詳細のレコード。

ユーザーの変更に関する追加情報を確認するには、SYS_USERLOG システムビューにクエリを実行します。このビューには、Amazon Redshift Serverless のログデータが含まれています。

ユーザーアクティビティログ

データベースで実行される前に記録した各クエリのログ。

監査ログと Amazon CloudWatch

Amazon Redshift の監査ログ作成はデフォルトではオンになっていません。クラスターでログ作成をオンにすると、Amazon Redshift は、監査ログが有効になった時点から現在までのデータをキャプチャするログを作成して Amazon CloudWatch にエクスポートするか、Amazon S3 にアップロードします。各ログの更新は、以前のログの続きとなります。

CloudWatch または Amazon S3 の監査ログ作成は、任意で、手動のプロセスです。システムテーブルへのログ作成は任意ではなく、自動的に作成されます。システムテーブルのログ作成の詳細については、Amazon Redshift データベースデベロッパーガイドのシステムテーブルのリファレンスを参照してください。

接続ログ、ユーザーログ、ユーザーアクティビティログを同時に有効にするには、AWS Management Console、Amazon Redshift API リファレンス、AWS Command Line Interface (AWS CLI) のいずれかを使用します。ユーザーアクティビティログについては、enable_user_activity_logging データベースパラメータも有効にする必要があります。監査ログ作成機能のみを有効にし、関連するパラメータを有効にしない場合、データベース監査ログは接続ログとユーザーログの情報のみを記録し、ユーザーアクティビティログの情報は記録しません。この enable_user_activity_logging パラメータはデフォルトでは有効になっていません (false)。ユーザーアクティビティログを有効にするには、このパラメータを true に設定します。詳細については、「Amazon Redshift パラメータグループを作成します。」を参照してください。

CloudWatch へのログ作成を有効にすると、Amazon Redshift はクラスター接続、ユーザー、およびユーザーアクティビティに関するログデータを、Amazon CloudWatch Logs のロググループにエクスポートします。ログデータは、スキーマ的には変更されません。CloudWatch はアプリケーションをモニタリングするために構築されており、リアルタイム分析を実行したり、アクションを実行するように設定したりできます。Amazon CloudWatch Logs を使用して、非常に耐久性が高いストレージにログレコードを保存できます。

CloudWatch を使用したログの表示は、Amazon S3 にログファイルを保存する代わりに推奨される代替手段です。多くの設定を必要とせず、特に他のサービスやアプリケーションのモニタリングにすでに使用している場合は、監視要件に適している可能性があります。

Amazon CloudWatch でのロググループとログイベント

エクスポートする Amazon Redshift ログを選択すると、Amazon CloudWatch Logs でログイベントをモニタリングできるようになります。Amazon Redshift Serverless のための新しいロググループは、次の (log_type がログタイプを表す) プレフィックスを使用して自動的に作成されます。

/aws/redshift/cluster/<cluster_name>/<log_type>

例えば、接続ログをエクスポートする場合、そのログデータは次のロググループに保存されます。

/aws/redshift/cluster/cluster1/connectionlog

ログイベントをロググループに対しエクスポートする際には、ログストリームが使用されます。サーバーレスエンドポイントのログイベント内で情報を検索するには、Amazon CloudWatch Logs コンソール、AWS CLI、または Amazon CloudWatch Logs API を使用します。ログデータの検索およびフィルタ処理の詳細については、「フィルターを使用したログイベントからのメトリクスの作成」を参照してください。

CloudWatch では、粒度と柔軟性を提供するクエリ構文を使用してログデータを検索できます。詳細については、「CloudWatch Logs Insights クエリ構文」を参照してください。

Amazon CloudWatch 監査ログ作成に移行する

ログを Amazon S3 に送信している場合に、CloudWatch にログを送信するなど、設定を変更しても、Amazon S3 に残っているログは影響を受けません。そのデータが格納されている Amazon S3 バケット内で引き続きログデータをクエリすることができます。

Amazon S3 でのログファイル

Amazon S3 の Amazon Redshift のログファイルの数とサイズは、クラスターのアクティビティによって大きく異なります。大量のログを生成しているアクティブなクラスターがある場合、Amazon Redshift はより頻繁にログファイルを生成することがあります。同じ時間に複数の接続ログがあるなど、同じタイプのアクティビティに対して一連のログファイルが存在する場合があります。

Amazon Redshift が Amazon S3 を使用してログを保存する場合、Amazon S3 で使用するストレージの料金が発生します。Amazon S3 にログ作成の設定を行う前に、ログファイルをどのくらいの期間保存する必要があるかのプランを必ず作成してください。この作業の一環として、監査の必要性に応じてログファイルをいつ削除またはアーカイブできるかを決定します。作成するプランは、コンプライアンス要件または規制要件に従ったデータなど、保存するデータの種類によって大きく異なります。Amazon S3 料金の詳細については、Amazon Simple Storage Service (S3) の料金を参照してください。

Amazon S3 へのログ記録を有効にする場合の制限事項

監査ログ記録には以下の制約があります。

Amazon Redshift 監査ログ作成のためのバケットのアクセス許可

Amazon S3 へのログ作成をオンにすると、Amazon Redshift はログ作成情報を収集し、Amazon S3 に保存されたログファイルにアップロードします。新しいバケットを作成することも、既存のバケットを使用することもできます。Amazon Redshift には、バケットに対して以下の IAM アクセス許可が必要です。

監査ログ作成を有効にするときにに新規バケットを作成するオプションを選択すると、正確なアクセス許可がバケットに適用されます。ただし、Amazon S3 で独自にバケットを作成する、または既存のバケットを使用する場合、必ずバケット名を含むバケットポリシーを追加してください。ログは、サービスプリンシパルの認証情報を使用して配信されます。ほとんどの場合のAWS リージョンでは、Redshift サービスプリンシパル名、 redshift.amazonaws.comです。

このバケットポリシーでは、次の形式を使用します。ServiceName と BucketNameは独自の値のプレースホルダーです。バケットポリシーで、関連付けられたアクションとリソースも指定します。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "Put bucket policy needed for audit logging",
            "Effect": "Allow",
            "Principal": {
                "Service": "ServiceName"
            },
            "Action": [
                "s3:PutObject",
                "s3:GetBucketAcl"
            ],
            "Resource": [
                "arn:aws:s3:::BucketName",
                "arn:aws:s3:::BucketName/*"
            ]
        }
    ]
}

次の例は、米国東部（バージニア北部）リージョン、および AuditLogsという名前のバケットのバケットポリシーです。

{
    "Version": "2008-10-17",
    "Statement": [
        {
            "Sid": "Put bucket policy needed for audit logging",
            "Effect": "Allow",
            "Principal": {
                "Service": "redshift.amazonaws.com"
            },
            "Action": [
                "s3:PutObject",
                "s3:GetBucketAcl"
            ],
            "Resource": [
                "arn:aws:s3:::AuditLogs",
                "arn:aws:s3:::AuditLogs/*"
            ]
        }
    ]
}

デフォルトで有効になっていないリージョン (「オプトイン」リージョンとも呼ばれます) には、リージョン固有のサービスプリンシパル名が必要です。これらの場合、サービスプリンシパル名には、 redshift.region.amazonaws.comという形式でリージョンが含まれます。たとえば、redshift.ap-east-1.amazonaws.com は、アジアパシフィック (香港) リージョンの 1 つです。デフォルトで有効になっていないリージョンの一覧については、AWS 全般のリファレンスの「AWS リージョンの管理」を参照してください。

ログファイルのベストプラクティス

Redshift が Amazon S3 にログファイルをアップロードする場合、大きなファイルを部分的にアップロードできます。マルチパートアップロードが成功しなかった場合、ファイルの一部が Amazon S3 バケットに残っている可能性があります。これにより、追加のストレージコストが発生する可能性があるため、マルチパートアップロードが失敗した場合に何が起きるかを理解することが重要です。監査ログのマルチパートアップロードの詳細については、マルチパートアップロードを使用したオブジェクトのアップロードとコピー と マルチパートアップロードの中止を参照してください。

Amazon S3 バケットの作成とバケットポリシー追加の詳細については、 Amazon Simple Storage Service コンソールユーザーガイドの バケットの作成 と バケット許可の編集 を参照してください。

Amazon Redshift 監査ログ作成のバケットの構造

デフォルトでは、Amazon Redshift は Amazon S3 バケット内のログファイルの整理に以下のバケットおよびオブジェクト構造 を使用します。

AWSLogs/AccountID/ServiceName/Region/Year/Month/Day/AccountID_ServiceName_Region_ClusterName_LogType_Timestamp.gz

例: AWSLogs/123456789012/redshift/us-east-1/2013/10/29/123456789012_redshift_us-east-1_mycluster_userlog_2013-10-29T18:01.gz

Amazon S3 のキープレフィックスを指定すると、キーの冒頭にプレフィックスが挿入されます。

たとえば、myprefix のプレフィックスを指定する場合: myprefix/AWSLogs/123456789012/redshift/us-east-1/2013/10/29/123456789012_redshift_us-east-1_mycluster_userlog_2013-10-29T18:01.gz

Amazon S3 のキープレフィックスは 512 文字を超えることはできません。スペース ( )、二重引用符 (“)、一重引用符 (‘)、バックスラッシュ (\) を含めることはできません。また、許可されない特殊文字、および制御文字もいくつかあります。これらの文字の 16 進コードは次のとおりです。

Amazon S3 での監査ログ記録に関する考慮事項

Amazon Redshift 監査ログ作成は、以下の理由で中断されることがあります。

AWS CloudTrail を使用した API コール

Amazon Redshiftは、Amazon Redshift 内のユーザー、ロール、または AWS サービスによって実行されたアクションのレコードを提供するサービスである AWS CloudTrailと統合されています。CloudTrail のすべての API コールをイベントとして Amazon Redshift にキャプチャします。Amazon Redshift と AWS CloudTrail の統合の詳細については、「CloudTrail によるログ記録」を参照してください。

CloudTrail は、Amazon Redshift データベース監査ログ作成から独立して、または追加して使用できます。

CloudTrail の詳細については、 AWS CloudTrail ユーザーガイドを参照してください。