Alibaba Cloud の監査設定（ActionTrail） #Security

パブリッククラウドの利用にあたり、セキュリティ監査（操作履歴保存と追跡等）は重要な機能です。
本項では、Alibaba Cloud のリソース操作履歴を自動的に記録するActionTrail について紹介します。

はじめに

Alibaba Cloud とは

阿里巴巴集団（アリババグループ）が提供するパブリッククラウドサービスです。
米調査会のクラウドインフラ市場リサーチ¹ では、堅調にシェアを伸ばし、Amazon、Microsoft、IBM、Googleに次ぐ市場5位に立っています。また、少々古い記事ですが、CPU供給大手のIntel社からは「スーパー7」²の一角として優遇されているようです。

Alibaba Cloud におけるActionTrail の位置づけ

ActionTrailの利用により、現状、「不正アクセス有無の確認」が可能です。

ActionTrail は、リソース操作を記録する機能であり、記録元や保管先等の他リソースと連動する必要があります。
Alibaba Cloud機能は複数あり、ActionTrailの位置づけを簡単に図解すると下記のようなイメージです。

ActionTrail で取得可能な操作履歴（2018年5月現在）

前述の図の「各リソース操作」ボックスに略称を記載していますが、ActionTrailで操作履歴が取得可能なリソースはすべてではありません。（リンク参照³）

また、取得可能な情報は下記の通りです。

主要な監査項目	ActionTrail項目名
いつ（When）	・イベント時間：（操作日時）
誰が（Who）	・ユーザー名：（操作を実施したユーザー ID）・ソース IPアドレス：（操作クライアントの IP アドレス）
どこで（Where）	・リージョン：・要求 ID：（操作対象リソース ID）
何をした（What）	・イベント名：（操作内容）・イベントソース：・エラーコード：（操作終了コード (成功/失敗)）

ActionTrailは、通常ユーザー操作後、10分以内に操作履歴を記録されます。

ActionTrail管理コンソール上で確認可能な操作履歴は、「過去7日間」となり、この期間を過ぎると履歴が確認できなくなるため、Object Storage Service（OSS）へのログ保管設定を行います。（「基本設定と操作方法」で解説します）
特にセキュリティ監査観点だと、ログの保管期間に関するセキュリティポリシー（情報管理規則等）が作成されている組織が多いです。（現状のデフォルト7日間では、まず足りないかと思います）

ActionTrail のログ保管とコストについて

ActionTrailの利用（有効化および7日間分の操作履歴の検索）は無料です。⁴

ただし、7日間以上の保管要件があり、OSSのバケットに出力する場合、OSSへの保管コスト⁵がかかります。
アカウントのリージョン毎の操作履歴を「トレイル」としてOSSバケットに圧縮保管可能であり、OSSはECS等のコンピュートリソースと比較し安価ですので、OSSへの保管まで含めて設定することが監査観点で推奨です。

ActionTrail を使う前に

本題のActionTrail による監査設定をする前に、アカウント運用ルールを決める必要があります。
具体的には、「アカウントのroot をつかわないこと」「RAM ユーザーを共有しないこと」の2つです。

Alibaba Cloud の利用申請/登録後は、rootアカウントが作成されます。
最初の作業はroot で行いますが、すぐにResource Access Management (RAM) を有効化し、Byname（名指し）でのRAMユーザーを作成してください。
本項ではRAMおよびアカウントの権限管理は深堀りしませんが、下表の例のように、ユーザー名をByname で管理しないと、前述の操作履歴で「誰が（Who）」を追跡できなくなります。

アカウント運用ルール例

ユーザー名	位置づけ	利用用途	運用ルール例
root	特権ID	アカウント全権操作/契約管理	通常運用での利用禁止（担当者でパスワード管理するのではなく金庫にいれてもいいでしょう）
Ichiro-Alibaba	ユーザーID（管理者）	RAMユーザー作成/権限付与用	管理者や利用ユーザーのID提供と離任者削除用
Jiro-Alibaba	ユーザーID（開発者）	ECS/RDSリソース管理用	開発用リソース（サーバ/DB等）管理用

ActionTrai基本設定

★ここからroot アカウント作業

Alibaba Cloudアカウント登録直後の各サービスは下記画面が表示されるため、まず、ActionTrailとOSS、RAMのサービスを有効化します。

3つのサービス有効化の後、ActionTrailの「トレイル設定（OSSへのログ出力」を行います。
出力先のOSSのリージョン（下図では「Asia Pacific NE 1 (Tokyo)」）を確認し、「トレイルの作成」をクリックします。

下記入力例では出力先のOSSバケットをActionTrail から作成・出力する流れのため、リソース間のアクセス許可の確認画面が表示されます。

確認画面を押すと、下記同意画面が表示されます。
ActionTrailと各リソースとの連携に関する権限設定は、初期設定では下図デフォルトのロールを利用すると問題が起こりにくいです。

筆者の環境では、権限付与に同意後、トレイルが作成されないまま画面に戻りました。（権限付与およびOSSバケットは作成完了）
これは権限付与操作が発生すると、その操作はいったんエラーとして中断するためと思われます。（ActionTrailのイベント「CreateTrail」に「NeedRamAuthorize」のエラーコードが出力されていました）

このため、再度、トレイルの作成を行いました。（今回は既存バケットを指定・下図左画面参照）
なお、下図右画面の通り、ログファイルプレフィックスは、フォルダとなるため、指定しておくとActionTrailログを将来整理しやすくなるので、指定を推奨します。

★ここまでroot アカウント作業

これでActionTrailの初期設定は終了です。
下図のとおり、OSSバケットにもActionTrailの圧縮されたログが保存されはじめます。本項では割愛しますが、この後、RAMユーザーの作成を行い、各ユーザー毎に適切な権限を付与してください。

想定シナリオに基づくActionTrailの操作方法

さて、冒頭でActionTrailは、「不正アクセス有無の確認」が可能と記載しましたが、ActionTrailの画面から確認してみます。（7日以降経過したOSSバケット上のログ解析は本項では割愛します）

シナリオ１．不正アクセス有無の確認

下図は、RAMユーザーのコンソールログイン成功・失敗の事例です。
RAMユーザー「Jiro-Alibaba」で意図的に3回パスワードをご入力した後に正常にログインした操作履歴です。例えば、夜間や休日等のログイン履歴を見直すことで、身に覚えのない不信なログインを確認できます。

ただし、例えば「Test-User」という存在しないRAMユーザーでのログイン失敗は表示されませんので、辞書攻撃やパスワードリスト攻撃のような総当たり攻撃の対策は、多要素認証（MFA）を利用します。

Alibaba Cloud のログイン画面は、rootアカウント用とRAMユーザー用があり、前者にはCAPTCHA認証がデフォルトでありますが、どちらもMFA認証を設定します。（こうした攻撃の検知はActionTrailの範囲外と思われます）

また、下記のようにroot アカウントは通常利用で使用するには強すぎる権限をもっているので、履歴に表示された場合は、正規の手続きに基づく利用かどうか確認する必要があるでしょう。

シナリオ２．不許可作業等、不正操作有無の確認

現場担当者間の不正なパスワードの受け渡しやパスワード漏えいに端を発する不正操作についてです。

下図は「OSSバケットへのReadonlyアクセス権」のみをもつ「Saburo-Alibaba」の操作履歴ですが、イベント名にあるようにVPCを作成しようとしましたが、権限不足でエラーが表示されていました。
利用承認されていないリソースのリンクをクリックすることはありえても、そのリソースの作成操作まで進むことは、RAMユーザー利用を許可した側からすると問題です。
自身の権限を理解しているか、不正利用されていないか「Saburo-Alibaba」の利用者に確認する必要があるでしょう。

シナリオ３．定期監査すべきイベント名

現在、サポートされているActionTrailで記録可能なリソースは参考リンク⁴ の通りです。
一例として、下記のようなイベントは定期的に集計、監視しておくと不正利用の検知・けん制や被害防止となります。

リソース名	イベント名	イベント動作	監視目的
ECS APIs recorded	CreateInstance	ECS仮想マシンの作成	不正な仮想マシンの作成ではないか
ECS APIs recorded	DeleteInstance	ECS仮想マシンの削除	不正な仮想マシンの削除ではないか
ECS APIs recorded	CreateSecurityGroup等、SecurityGroupを含むイベント	Firewallの操作	不正なFirewall設定が行われていないか
RAM APIs recorded	すべて	RAMユーザー作成や権限変更	不正な権限付与やユーザーが作成されていないか

シナリオ４．情報漏えい時の怪しいユーザーを特定する

現状、ActionTrail 単独では難しいと思われます。
下記公式ドキュメントの引用の通り、リソース内に保管されているデータ抽出を特定するイベントは存在しないか、他のログと合わせ技で追跡する必要があります。

ActionTrail では、リソースに対する追加、変更、削除操作が主に記録されます。リソースに対する取得、クエリ、確認操作は記録されません。

まとめ

監査観点でActionTrailの機能を検証してみましたが、サマリは下記のとおりです。

1. Alibaba Cloud アカウント作成/登録直後に、本機能を有効化し、OSSバケットへのログ出力を設定する
2. ActionTrailのコンソールで追跡できる操作履歴は7日分（2018年5月現在）のため、過去追跡のためOSSバケット保管ログの分析手法を検討する
3. 操作履歴を取得できるリソースは限られているため、監査要件やリスクシナリオを整理し、ActionTrailで対応不可能なリスクを把握する

今後、ActionTrail機能は拡張されていくと思われますので、Alibaba Cloud 本番運用の主要機能として注目していきたいと思います。