クラウドの利用において、各サービスのリソースに関するログは、トラブル対応や監査において非常に重要です。
しかし、Google Cloudのログは初期設定では一定期間しか保存されず、それ以降は古いログから順に削除されます。そのため、トラブルが発生した際に、問題がいつから発生していたのかを特定できず、原因究明や今後の対応方針を決めることが難しくなります。
このような事態を避けるために、今回はGoogle Cloudのログを長期間保存する方法について説明します。また、ログの容量が増えるとコストがかかるため、一定期間後にログを低コストな媒体に保存する方法もご紹介します。
Google Cloudの管理者や監査担当者にとって必見の内容です。
是非、最後までご覧いただけると嬉しいです。
ログの種類
Google Cloudの主なログには、2つあります。
- 監査ログ（Audit Logs）
- サービス固有のログ
監査ログ（Audit Logs）
Google Cloudの監査ログ（Audit Logs）とは、Google Cloud Platform上で誰が、いつ、どのリソースに対して、どのような操作を行ったかを記録するログです。これにより、システムへの不正アクセスや誤操作の検出、セキュリティ監査、コンプライアンスへの対応などを支援します。
監査ログには以下の4つのログが含まれます。
- 管理アクティビティ監査ログ
- データアクセス監査ログ
- システム イベント監査ログ
- ポリシー拒否監査ログ
1. 管理アクティビティ監査ログ
Google Cloudの管理アクティビティ監査ログは、Google Cloud Platform上のリソースに対する重要な変更を記録するログです。仮想マシンの作成、ストレージバケットの削除、IAMポリシーの変更など、システム構成に影響を与える操作が記録されます。これにより、誰が、いつ、どのような変更を行ったかという履歴を把握できます。このログは、いかなる場合でも無効にすることはできません。
2. データアクセス監査ログ
Google Cloudのデータアクセス監査ログは、Google Cloud上のデータへのアクセスを記録するログです。具体的には、誰が、いつ、どのデータを、どのような操作でアクセスしたかという詳細な情報が記録されます。これにより、データ漏洩の発生源の特定や、不正アクセス検知、データ利用状況の分析などが可能になります。初期設定では、無効になっていますが、後で有効にする方法について説明します。
3. システム イベント監査ログ
Google Cloudのシステム イベント監査ログは、システム自体が実行したアクションを記録するログです。ユーザーの操作ではなく、システムの内部的な処理によって発生したイベントが記録されます。例えば、仮想マシンの自動スケーリング、ディスクの自動スナップショット作成などが挙げられます。このログは、いかなる場合でも無効にすることはできません。
4. ポリシー拒否監査ログ
Google Cloudのポリシー拒否監査ログは、ユーザーやサービスアカウントが、設定されたポリシーに違反しようとした際に、そのアクセスが拒否されたことを記録するログです。IAMポリシーや組織ポリシーなど、設定されたアクセス制御ルールに合致しなかったアクセス試行が詳細に記録されます。基本的に無効にすることはできませんが、除外フィルタを使用してログバケットに保存されないようにすることはできます。フィルタについては、別のブログで説明する予定です。
サービス固有のログ
サービス固有のログは、各Google Cloudサービスが生成する詳細なログデータです。これらのログには、サービスの動作状況、エラーメッセージ、リクエスト・レスポンスの詳細などが記録されており、問題の特定、トラブルシューティング、システムの最適化に役立ちます。
ログの保管場所
ログは、初期設定では、Cloud Logging バケットに保存されます。しかし、一定期間がたつと自動的に削除されます。ログを長期で保管したい場合、他のリソースに保管することができます。これをログシンク（log sink）と呼びます。一般的によく使用されているのが、以下２つです。
- BigQuery データセット
- Cloud Storage バケット
どちらを使用すべきかについて、私の考えでは、ログを分析したい場合はBigQueryデータセットを選ぶべきで、コストを抑えたい場合はCloud Storageバケットが適しています。Cloud StorageではログがJSON形式で保存されるため、検索や分析にはやや使いづらいです。そのため、コストを抑えつつ、監査やトラブル対応用に保存する場合にはCloud Storageバケットを選択するのが良いと思います。
今回は、ログの保管場所にCloud Storage バケットを使用する方法について説明します。
ログバケットの作成方法とライフサイクル設定
それでは、Cloud Storage バケットの作成方法と、一定期間後にストレージクラスを変更する方法、およびログを削除する方法について説明します。
手順は、以下３ステップです。
- データアクセス監査ログの有効化
- ログバケットの作成
- ライフサイクル設定
1つずつ詳しく説明します。
1. データアクセス監査ログの有効化
まず、データアクセス監査ログの有効化手順について説明します。通常は組織階層で有効化するのが一般的ですが、今回はプロジェクト階層で設定しています。ただし、設定方法はどちらも同じです。
まずは、サイドバー又は上の検索窓に「監査ログ」と入力し、監査ログを開きます。
今回は、すべてのGoogle Cloud サービスにおけるデータアクセス監査ログを有効にします。
コンソール上部の「デフォルト構成の設定」を開きます。
「管理読み取り」「データ読み取り」「データ書き込み」の３つのチェックを入れ、「保存」を選択します。
ちなみに、「管理書き込み」は初期設定で有効になっており、無効化することはできません。「管理書き込み」とは、リソースの作成や更新などの処理を指します。
「データ書き込み」とは、Google Cloud のサービスにおいて、データを作成、変更、または削除する操作を指します。具体的な例としては、Cloud Storage のバケット内でのオブジェクトの作成、更新、削除のアクションや、BigQuery のデータセット内でのテーブルの作成、変更、削除などが含まれます。これらはすべて、各リソースに対する実際のデータの操作に該当します。
正常に有効化されると、すべての権限の種類に「有効」と表示されます。
以上で、データアクセス監査ログの有効化方法の説明は終わりになります。
2. ログバケットの作成
次は、Cloud Storageでログ用のバケットを作成する方法について説明します。
サイドバー又は上の検索窓に「Cloud Storage」と入力し、Cloud Storageを開きます。
次に、バケットを作成するため、コンソール上部の「作成」を選択します。
Cloud Storage バケットは、全5ステップで作成することができます。
まず、バケット名を指定します。バケット名は全世界で一意である必要があり、他の人と重複している場合は作成できません。
今回は、「log-bucket-audit-log」にしています。必要に応じてラベルを設定します。ラベルについは、別のブログで説明する予定です。最後に「続行」を選択します。
次にリージョンを選択します。基本的には、天災などを考慮して、複数のリージョンにすることを推奨しますが、今回は、手順説明のため、シングルリージョンを選択します。
料金節約のため、米国リージョンを選択しています。選択後、「続行」を選択します。
次にストレージクラスを選択します。初期設定では、データアクセス監査ログは30日間、Cloud Logging バケットに保存されます。
今回は、コストを抑えるため、Nealineを選択します。選択後、「続行」を選択します。
次は、アクセス制御の設定を行います。今回は、きめ細かい設定は行わないので「均一」にします。また、「公開アクセスの防止」は、バケットをインターネット上に公開するかの設定です。ログバケットは、監査・トラブル対応用に使用するので、「このバケットに対する公開アクセス禁止を適用する」にチェックを入れます。最後に「続行」を選択します。
最後に、オブジェクトデータの保護と暗号化に関する設定を行います。最近、オブジェクトを削除してから一定期間そのオブジェクトを復元できる「削除ポリシー」機能が追加されました。初期設定は、7日間オブジェクトを復元することができます。
今回は、すべての設定を、初期設定のまますすめます。最後に「作成」を選択します。
正常にバケットが作成されると、バケットが表示されます。
以上で、ログバケットの作成に関する説明は終わりになります。
3. ライフサイクル設定
最後にライフサイクル設定を行います。ライフサイクル設定は、様々な条件から、ログが保存されているストレージクラスを変更したり削除するための設定です。ストレージクラスやオブジェクトを削除することで、コストを抑えることができます。
今回は、ログがバケットに保存されてから180日後に「Coldline」に移動し、270日後に「Archive」に移動し、365日後に「削除」する設定を行います。
「ライフサイクル」を選択します。
次に、「ルールを追加」を選択します。
180日後に「Coldline」に変更するルールを作成します。
「ストレージ クラスをColdlineに設定する」を選択し、「続行」を選択します。
次に、アクションの条件を設定します。条件は、様々な要素から設定することができますが、今回は、ログがバケットに保存されてから180日後にストレージクラスを変更するので、「経過日数」を選択し、「180」と入力します。
ちなみに、ログシンクを設定すると、ログは記録され次第、すぐにログバケットに保存されます。そのため、ログがログバケットに保存されるまでの猶予期間はありません。
入力後、最後に「作成」を選択します。
正常にルールが作成されると、ルールが追加されます。
同じ要領で、270日後にArchiveに移動するルールと365日後に削除するルールを作成します。
「ルールを追加」を選択し、以下設定を行います。
- アクションを選択：ストレージクラスをcoldlineに設定する
- オブジェクト条件の選択：経過日数、270日
もう一つ、以下のルールを作成します。
- アクションを選択：オブジェクトを削除する
- オブジェクト条件の選択：経過日数、365日
正常にルールが作成されると、以下のようになります。
このように、ライフサイクルルールを作成することで、保存されたログを一定期間後にストレージクラスを変更したり削除することで、コストを抑えることができます。
以上で、ログバケットの作成方法とライフサイクル設定の説明は終わりになります。
ログシンクの設定
最後に、ログシンクの設定を行います。
サイドバー又は上の検索窓に「ログルーター」と入力し、ログルーターを開きます。
コンソール上部の「シンクを作成」を選択します。
「シンク名」を入力します。「シンクの説明」の入力は任意です。ここでは以下にしております。
- シンク名：log-sink-storage-bucket
- シンクの説明：ストレージバケットに監査ログを保管用ログシンク
入力後、「次へ」を選択します。
シンクの宛先を設定します。
「シンクサービスの選択」は、「Cloud Storage バケット」を選択し、下の「Cloud Storage バケット」の入力欄の右端にある「参照」を選択します。
先程作成した「log-bucket-audit-log」を選択し、「選択」を選択します。上記の画面に戻ったら「次へ」を選択します。
「シンクに含めるログの選択」では、ログシンクに含めるログを指定することができます。
今回は、すべてのログをログシンクで保管するので「次へ」を選択します。
「シンクに含めないログの選択」では、ログシンクに含めないログを指定することができます。
今回、すべてのログをシンクするので、「シンクを作成」を選択します。
正常にログシンクが作成されると、ログルーター シンクの一覧に表示されます。
しばらくすると、ログバケットにログが保管されます。
このように、ログシンクを設定することで、通常、ログは一定期間後に削除されますが、長期間保管することができます。
以上で、ログシンクの設定方法に関する説明は終わりになります。
まとめ
今回は、下記４点について説明しました。
- ログの種類
- ログの保管場所
- ログバケットの作成方法とライフサイクル設定
- ログシンクの設定
Google Cloudのログを長期間保管したい場合は、ログシンクとストレージを併用することで、実装することができます。Google Cloudのログは、トラブルや障害発生時に、有益な情報を提供してくれるとても重要なリソースです。ログシンクを設定して、みなさんのGoogle Cloudの利用に役立ててください。
これからも、Macのシステムエンジニアとして、日々、習得した知識や経験を発信していきますので、是非、ブックマーク登録してくれると嬉しいです！
それでは、次回のブログで！
