Blog
AWSルートユーザの管理とKibana (Watcher)を使った利用検知
こんにちは、アドテクスタジオでセキュリティエンジニアをしている岡崎です。
今回は、「AWSルートユーザの管理とKibana (Watcher)を使った利用検知」について、紹介させていただきます。
アドテクスタジオではAWS利用において、ルートユーザの利用を制限しています。
ルートユーザはAWSの中でとても強い権限を持ち、AWSの解約もできてしまうほどです。
また、ルートユーザのように一意のユーザに紐付かないアカウント（共用アカウント）は、セキュリティ事故のときに「誰が操作したか、分からない」という事態に陥ることがあります。
そのため、アドテクスタジオではルートユーザはセキュリティチームが管理し、利用者にはフェデレーションユーザでのログインを推奨しています。
＊詳しくは、前回のブログを参照してください。
AWS Management ConsoleへのSSO ー PingFederateのインストール編
https://cyberagent.ai/techblog/archives/2811
AWS Management ConsoleへのSSO ー PingFederateの設定編
https://cyberagent.ai/techblog/archives/2822
ですが、以下のようにルートユーザでないと、できないこともあります。
・ルートユーザーの詳細の変更。これには、ルートユーザーのパスワードの変更が含まれます。
・AWS のサポートプランの変更。
・支払オプションの変更、または削除。
・アカウントの請求情報の参照。IAM ユーザーの請求へのアクセスを有効にする方法についての詳細は、「請求情報およびコスト管理コンソールへのアクセスのアクティベート」を参照してください。
・AWS アカウントの解約。
・GovCloud へのサインアップ。
・Amazon EC2 リクエストの逆引き DNS を送信します。リクエストを送信するためのページ上の「このフォーム」のリンクは、ルートユーザー認証情報でサインインする場合にのみ動作します。
・CloudFront のキーペアの作成。
・AWS 作成の X.509 署名証明書の作成。(IAM ユーザー用に自己作成証明書を作成することはできます。)
・Amazon Route 53 ドメインを別の AWS アカウントに転送。
・長いリソース ID の Amazon EC2 設定の変更。ルートユーザーとしてこの設定を変更すると、アカウントのすべてのユーザーとロールに影響します。IAM ユーザーまたは IAM ロールとして変更すると、そのユーザーまたはロールにのみ影響します。
・AWS インフラストラクチャで侵入テストを実行するリクエストを送信します。
・AWS サポートケースを開き、[Regarding: Account and Billing Support] を指定します。
・EC2 インスタンスでのポート 25 による E メールのスロットリングの削除をリクエストします。
・AWS アカウントの正規ユーザー ID を検索します。
参考： http://docs.aws.amazon.com/ja_jp/general/latest/gr/aws_tasks-that-require-root.html
上記の中でも、アドテクスタジオでは以下の操作時にルートユーザを使うことが多いです。
・AWS のサポートプランの変更。
・Amazon Route 53 ドメインを別の AWS アカウントに転送。
・AWS インフラストラクチャで侵入テストを実行するリクエストを送信します。
上記のような操作のときにルートユーザが利用されたかが「わかるように」なっている仕組みが必要です。
そこで、アドテクスタジオでも利用しているKibanaのWatcher機能を活用した検知とアラート送信を簡単に説明します。
以下は、大まかな流れになります。
＊AWS CloudTrailからElasticSearchへのログ転送は、今回は詳細な説明は割愛します。
Kibanaの新規サービスX-Packのひとつの機能である「Watcher」の活用を中心に説明させていただきます。
X-Packとは、ElasticSearchとKibanaにさらに利用しやすくしてくれるオプションになります。
Security・Alerting・Monitoring・Reporting・Graph・Machine Learningような様々な機能があり、今回はAlerting (Watcher 経由)の活用になります。
X-Packインストール
＊ElasticSearchとKibanaはインストールされているものとします
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
# 一時、サービス停止 systemctl stop elasticsearch systemctl stop kibana ＊データ量によっては時間が時間がかかります /usr/share/elasticsearch/bin/elasticsearch-plugin install x-pack ………… systemctl restart elasticsearch /usr/share/kibana/bin/kibana-plugin install x-pack systemctl restart kibana ＊ 初期ユーザーはユーザー名がelastic、パスワードがchangemeです。 ＊セキュリティ（ログインが不要）の場合は、無効にする。有効になっていると、ElasticSearchにデータをPOSTする際にも認証が必要になります。 # vi /etc/elasticsearch/elasticsearch.yml xpack.security.enabled: false ＊xpack.security.enabledのsecurityをmonitoring、graph、watcher、reportingにすることでそれぞれの機能を無効化設定することができます。 |
Kibana – WatcherからのSlackへのアラート通知のため、Webhook URLの設定
＊対象Slackのチャンネルを作りWebhook URLを準備してください。
|
1 2 3 4 5 6 7 8 |
# vi /etc/elasticsearch/elasticsearch.yml 〜省略〜 xpack.notification.slack: account: このWebhookURLの名称: url: https://hooks.slack.com/services/xxxxxxxxxxxxxxxxxxxxxxxx ＊ElasticSearchを再起動してください |
これで下準備は完了になります。
続いて、ルートアカウントでのAWSマネジメントコンソールへのログインを検知し、アラート通知したい場合の設定
Watcherの例
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 |
{ "trigger": { "schedule": { "interval": "5m" // チェック間隔 } }, "input": { "search": { "request": { "search_type": "query_then_fetch", "indices": [ "aws-cloudtrail-log" // 対象のログ ], "types": [], "body": { "query": { "query_string": { "fields": [ "Username", // 対象のフィールド名 "EventName" ], "query": "root AND ConsoleLogin" // 条件値 } } } } } }, "condition": { "compare": { "ctx.payload.hits.total": { "gt": 0 // １回以上でアラート } } }, "actions": { "notify-slack": { "throttle_period_in_millis": 600000, "slack": { "account": "monitoring", // elasticsearch.ymlで設定した値 "message": { "from": "watcher", "to": [ "#channelname" ], "text": " ルートユーザでログインされました。 " //Slackに投稿するメッセージ } } } } } |
＊inputの条件の書き方はさまざまですので、色々試してみてください。
参考：
https://www.elastic.co/guide/en/elasticsearch/reference/5.5/watcher-api-put-watch.html
https://www.elastic.co/guide/en/elasticsearch/reference/current/query-dsl.html
https://www.elastic.co/guide/en/x-pack/5.5/actions-slack.html
上記の設定により、AWSにマネジメントコンソールにルートアカウントで１回以上ログインされるとSlackにアラートが通知されます。
ぜひ、お試しください。
おまけ
今回、Route53のログが取得できないので調べていたところ、以下のような条件があることに気づきました。
Route53などのCloudTrailは「米国東部（バージニア北部）us-east-1」に保存されるので、注意しましょう。
Amazon Route 53 向けの CloudTrail の設定
AWS アカウントによって行われた API リクエストに関する情報をキャプチャするように CloudTrail を設定するときは、まずリージョンを選択します。Amazon Route 53 の場合、リージョンとして [米国東部（バージニア北部）] を選択する必要があります。そうしないと、Amazon Route 53 API リクエストのログエントリを取得できません。
おわりに
今回は、「AWSルートユーザの管理とKibana (Watcher)を使った利用検知」について、紹介させていただきました。
Watcherの設定はJSONでの記述のため、多少クセがあります。。。こちら改善されることを願ってます。
アドテクスタジオでは複数のAWSを一括で管理する必要があるため、すべてのCloudTrailのデータを集約し可視化するため、このような方法を取っています。
同様の要領でGCPのAudit Logに対しても、有効な方法だと思いますので、今度はそちらにも試してみようと考えてます。
Author
