Google Cloud

Cloud Audit Logging が多くの GCP サービスで利用可能に

2017年1月30日

Google Cloud Japan Team

Google Cloud Audit Logging は、Google Cloud Platform（GCP）で「誰が、何を、どこで、いつ行ったか」を特定するために役立ちます。この機能は昨年、一部の GCP サービスで利用できるようになりましたが、今回統合されるサービスを大幅に増やしました。

上記サービスとの統合は、現時点ではベータです。

また今回、Google Cloud Dataflow、Stackdriver Debugger、Stackdriver Logging 向けの Cloud Audit Logging を一般公開（GA）しました。

Cloud Audit Logging は、統合された各サービスのログストリームを作ります。ログストリームは主に管理アクティビティログで、サービスや個々のリソース、関連するメタデータの変更操作がエントリとして含まれます。

一部のサービスでは、データアクセスログも生成します。このログには、ユーザーが提供しサービスが管理するデータへのアクセスや変更を行う API コールに加え、メタデータを読み込む操作のエントリが含まれます。現時点でデータアクセスログを生成するのは Google BigQuery のみですが、今後は変わっていくでしょう。

Cloud Console で監査ログを利用する

Cloud Console の Activity ページでは、すべての監査ログの概要が確認できます。好きな項目をクリックし、イベントの詳細を確認してください。

https://storage.googleapis.com/gweb-cloudblog-publish/images/121413.max-1600x1600.png

デフォルトでは、このフィードの中にデータアクセスログは表示されません。表示を有効にするには、Filter 設定パネルの “Categories” にある “Data Access” を選択します（データアクセスログを確認するには、Private Logs Viewer の IAM パーミッションも必要です）。他にも、ユーザー、リソース種別、日時で表示結果をフィルタリングできます。

https://storage.googleapis.com/gweb-cloudblog-publish/images/eXiqqXiEtbn9Q0_X1Qix2IyGh89P8meoNRprruAFlL.max-1400x1400.PNG

Stackdriver で監査ログを利用する

監査ログは、Stackdriver ログビューアの他のログと同じように利用できます。ログビューアでは、リソースの種類やログ名（“activity” は管理アクティビティログ、“data_access” はデータアクセスログ）でログを選択して見るだけではなく、フィルタリングやテキスト検索もできます。

これは JSON フォーマットのログエントリの一部です。重要な部分をハイライトしています。

https://storage.googleapis.com/gweb-cloudblog-publish/images/1P2n_3wEcqzXnnRAO7Nx6PVvCaH9v45BvfMV7x0Nm3.max-1500x1500.PNG

ログの確認だけでなく、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 への呼び出しがあったときにアラートを発生させます。

https://storage.googleapis.com/gweb-cloudblog-publish/images/D9UxlBQnA2oFpfdDlijxIRdsDQkDqkKE_SIO4rfVnI_2.max-800x800.PNG

フィルタがイベントを正しく抽出していることを確認したら、画面上部にある “CREATE METRIC”（指標を作成）をクリックしてログベースの指標を作成します。

指標の名前と説明を入力し、その下の “Create Metric” をクリックします。指標が保存されたことを確認できます。

https://storage.googleapis.com/gweb-cloudblog-publish/images/0FKlA9eWQV7H4ORdXhyX-nqN3qStXmQqtlff1HhZi5PF.max-800x800.PNG

次に、左のメニューから “Logs-based Metrics”（ログベースの指標）を選択します。作成した指標が “User Defined Metrics” の下にあることを確認したら、その指標の右側にあるドットをクリックし、“Create alert from metric” を選択します。

https://storage.googleapis.com/gweb-cloudblog-publish/images/Y6UnzXghBtpr3_uSazRsU0kqOjDmycvY9lKG7EL26d.max-1600x1600.PNG

ここで、アラート発生の条件を作成します。今回は、先程指定したフィルタにマッチするログエントリが 1 つでもあるならとします。この条件にあわせ、閾値を “above 0”（0 以上）に設定します。

ログベースの指標では 1 分毎に現れたエントリの数をカウントします。期間は、この 1 分毎のレートを、アラートがトリガーされるまでの間どれくらい維持させるのかを指定する項目で、ここでは 1 分に設定します。例えば期間を 5 分に設定すると、5 分間の中で 1 分あたり少なくとも 1 度アラートの条件を満たせば、アラートがトリガーされます。

https://storage.googleapis.com/gweb-cloudblog-publish/images/buvud7fKAGwGVBdWEVFAyaIkArK2yV1HBvgVIuyKZe.max-1600x1600.PNG

最後に “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 以外のポートをオープンしたら問題ありと見なしています）。この関数を更新時も確認するように拡張するとしても、簡単にできるでしょう。

読み込んでいます...

Copyright 2017 Google Inc.
Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
'use strict';
exports.processFirewallAuditLogs = (event) => {
  const msg = JSON.parse(Buffer.from(event.data.data, 'base64').toString());
  const logEntry = msg.protoPayload;
  if (logEntry &&
      logEntry.request &&
      logEntry.methodName === 'v1.compute.firewalls.insert') {
    let cancelFirewall = false;
    const allowed = logEntry.request.alloweds;
    if (allowed) {
      for (let key in allowed) {
        const entry = allowed[key];
        for (let port in entry.ports) {
          if (parseInt(entry.ports[port], 10) !== 22) {
            cancelFirewall = true;
            break;
          }
        }
      }
    }
    if (cancelFirewall) {
      const resourceArray = logEntry.resourceName.split('/');
      const resourceName = resourceArray[resourceArray.length - 1];
      const compute = require('@google-cloud/compute')();
      return compute.firewall(resourceName).delete();
    }
  }
  return true;
};

ソースコードの index.js とは別に、この関数は gcloud Node.js モジュールを利用しているので、package.json に依存関係を加えます。

読み込んでいます...

次の画像で、関数で決められた基準をクリアできなかった新しいファイアウォールルールが、どうなったのかわかります（“bad-idea-firewall” と表示されています）。ここで重要なのは、この関数は過去にさかのぼって適用されないため、ポート 80 およびポート 443 へのトラフィックを許可する既存のファイアウォールルールはそのままだということです。