Cloud Audit Logging が多くの GCP サービスで利用可能に
Google Cloud Japan Team
Google Cloud Audit Logging は、Google Cloud Platform(GCP)で「誰が、何を、どこで、いつ行ったか」を特定するために役立ちます。この機能は昨年、一部の GCP サービスで利用できるようになりましたが、今回統合されるサービスを大幅に増やしました。
- Google Compute Engine
- Google Container Engine
- Google Cloud Dataproc
- Google Cloud Deployment Manager
- Google Cloud DNS
- Google Cloud Key Management Service(KMS)
- Google Cloud Storage
- Google Cloud SQL
また今回、Google Cloud Dataflow、Stackdriver Debugger、Stackdriver Logging 向けの Cloud Audit Logging を一般公開(GA)しました。
Cloud Audit Logging は、統合された各サービスのログ ストリームを作ります。ログ ストリームは主に管理アクティビティ ログで、サービスや個々のリソース、関連するメタデータの変更操作がエントリとして含まれます。
一部のサービスでは、データ アクセス ログも生成します。このログには、ユーザーが提供しサービスが管理するデータへのアクセスや変更を行う API コールに加え、 メタデータを読み込む操作のエントリが含まれます。現時点でデータ アクセス ログを生成するのは Google BigQuery のみですが、今後は変わっていくでしょう。
Cloud Console で監査ログを利用する
Cloud Console の Activity ページでは、すべての監査ログの概要が確認できます。好きな項目をクリックし、イベントの詳細を確認してください。デフォルトでは、このフィードの中にデータ アクセス ログは表示されません。表示を有効にするには、Filter 設定パネルの “Categories” にある “Data Access” を選択します(データ アクセス ログを確認するには、Private Logs Viewer
の IAM パーミッションも必要です)。他にも、ユーザー、リソース種別、日時で表示結果をフィルタリングできます。
Stackdriver で監査ログを利用する
監査ログは、Stackdriver ログ ビューアの他のログと同じように利用できます。ログ ビューアでは、リソースの種類やログ名(“activity” は管理アクティビティ ログ、“data_access” はデータ アクセス ログ)でログを選択して見るだけではなく、フィルタリングやテキスト検索もできます。これは JSON フォーマットのログ エントリの一部です。重要な部分をハイライトしています。
ログの確認だけでなく、Cloud Storage にエクスポートしての長期保存、BigQuery にエクスポートしての分析、Google Cloud Pub/Sub にエクスポートして他のツールと統合することもできます。このチュートリアルに、BigQuery の監査ログを BigQuery にエクスポートして、特定期間の BigQuery の利用量を分析する方法を記載しています。
Google Cloud Audit Logging は本当に使いやすく、BigQuery と統合すれば、すべてのアプリケーションを 1 か所で監視できる強力なツールになります。
Darren Cibis, Shine Solutions
パートナーとの統合
既に多くのログ分析ツールが世の中にあることは、私たちも認識しています。そこで、Splunk や Netskope、Tenable Network Security とパートナーシップを結びました。こちらのページにお気に入りのプロバイダーが掲載されていないならお知らせください。パートナーシップを結べるようにしていきます。Stackdriver のログ ベースの指標を利用したアラート
Stackdriver Logging にはログ ベースの指標を生成する機能があり、この指標を利用すれば Stackdriver のアラート ポリシーを決めることができます。ここでは例として、IAM ポリシーが変更される度にアラートを発生させるように指標やポリシーを設定する方法を説明します。最初にログ ビューアを開き、アラートを発生させるログを抽出できるように、フィルタを作ります。対象リソースのログが検索できるように、フィルタの範囲は正しく設定するようにしてください。今回のケースでは、SetIamPolicy
への呼び出しがあったときにアラートを発生させます。
フィルタがイベントを正しく抽出していることを確認したら、画面上部にある “CREATE METRIC”(指標を作成)をクリックしてログ ベースの指標を作成します。
指標の名前と説明を入力し、その下の “Create Metric” をクリックします。指標が保存されたことを確認できます。
次に、左のメニューから “Logs-based Metrics”(ログ ベースの指標)を選択します。作成した指標が “User Defined Metrics” の下にあることを確認したら、その指標の右側にあるドットをクリックし、“Create alert from metric” を選択します。
ここで、アラート発生の条件を作成します。今回は、先程指定したフィルタにマッチするログ エントリが 1 つでもあるならとします。この条件にあわせ、閾値を “above 0”(0 以上)に設定します。
ログ ベースの指標では 1 分毎に現れたエントリの数をカウントします。期間は、この 1 分毎のレートを、アラートがトリガーされるまでの間どれくらい維持させるのかを指定する項目で、ここでは 1 分に設定します。例えば期間を 5 分に設定すると、5 分間の中で 1 分あたり少なくとも 1 度アラートの条件を満たせば、アラートがトリガーされます。
最後に “Save Condition” を選んで、希望する通知方法(メール、SMS、PagerDuty など)を指定します。アラートのポリシーは、IAM コンソールで新しいパーミッションを与えるとテストできます。
Cloud Functions を利用して監査ログに対応する
Google Cloud Functions はライトウェイトで、イベント ベースの非同期処理を可能にするソリューションです。例えば特定のログ エントリのイベントに応答して、小さな専用の関数を実行できます。Cloud Functions は、JavaScript で書くことができ、Cloud Storage か Cloud Pub/Sub からのイベントをトリガーに、標準の Node.js 環境で実行されます。ログ エントリなら、ログを Cloud Pub/Sub のトピックにエクスポートすると Cloud Functions をトリガーします。Cloud Functions は現時点ではアルファ版です。プロジェクトで使いたいと考えているなら登録してください。例として、ファイアウォールのルールについて見ていきます。ルールの作成や変更、削除が行われると Compute Engine の監査ログ エントリが書き込まれます。ファイアウォールの設定情報は、監査ログ エントリのリクエスト フィールドに記録されています。次の関数は、新しいファイアウォールのルールを検査し、問題があるなら削除するというものです(ここでは、22 以外のポートをオープンしたら問題ありと見なしています)。この関数を更新時も確認するように拡張するとしても、簡単にできるでしょう。
ソース コードの index.js
とは別に、 この関数は gcloud Node.js モジュールを利用しているので、package.json
に依存関係を加えます。
次の画像で、関数で決められた基準をクリアできなかった新しいファイアウォール ルールが、どうなったのかわかります(“bad-idea-firewall” と表示されています)。ここで重要なのは、この関数は過去にさかのぼって適用されないため、ポート 80 およびポート 443 へのトラフィックを許可する既存のファイアウォール ルールはそのままだということです。
これは GCP の変更に応じて、Cloud Functions をどう活用できるのかを示す 1 つの例に過ぎません。
最後に
Cloud Audit Logging は、GCP 上に構築されたアプリケーションへのアクティビティを追跡する手段となり、ログを監視ツールやログ分析ツールと統合できるようにもします。Cloud Audit Logging や最新の GCP セキュリティに関する詳細な説明や訓練を希望されるなら、3 月にサンフランシスコで開催される Google Cloud Next '17 テクニカル ブートキャンプにお申し込みください。
* この投稿は米国時間 1 月 18 日、Product Manager である Joe Corkery によって投稿されたもの(投稿はこちら)の抄訳です。
- By Joe Corkery, Product Manager