トップ > AWS環境にCanaryTokenを仕掛け新たなセキュリティレイヤーを追加し監視する

AWS環境にCanaryTokenを仕掛け新たなセキュリティレイヤーを追加し監視する

記事タイトルとURLをコピーする

概要

　当エントリーでは、CanaryTokenついてざっくり理解しつつ、実際にAWS環境で監視する設定を仕掛ける手順を紹介していきます。

CanaryTokenとは

　センサーのように使える認証トークンです。

何故にカナリア(鳥) かというと、「炭鉱のカナリア」に由来します。 炭鉱夫が鳥籠を持っている写真や古い映画とかでその様子を見たことがある人もいるかもしれません。

掘り進めると人体に有毒なガスが発生する可能性のある危険な炭鉱にて、電子検出機器が普及する前の時代(1910〜80年代あたりまで) にそれを検知するための仕組みが、籠に入れたカナリアを先頭に歩く事だったのです。人間に比べ毒に敏感ですぐ弱ってしまう性質があるカナリアが鳴き止んだら、それは危険の前兆と捉える事が出来ます。

「Canary なんちゃら〜」 という言葉を見かけたら「人間に何らかの危険が迫っている前兆を察知する為のもの」という風にざっくり捉えて良いのかもしれません。

今回はAWS環境における Token なので、AWS Identity and Access Management (以後IAM) のアクセスキーとシークレットアクセスキーのセットのようなイメージを持って頂ければと思います。

ざっくり試して理解する

　そのまんまですが、canarytokens.org というサイトで CanaryTokenを無料で利用できるサービスがあります。実際にAWS環境で設定をしていく前に、どのような物なのかまずは理解する為にもこちらから試していきます。

今回は、AWSを利用したサンプルのみとなりますが、他にもDNSやらURIやら様々なファイル形式やら色々とあるので興味があれば自己責任で実施してみてください。 (ローカルにダウンロードする物の場合は、場合によってセキュリティ製品とかで検知されるかもしれません)

canarytokens.org のトップ画面にブラウザからアクセスします

canarytokens.org

作成するトークンの種類をプルダウンから選択します。今回は [AWS Keys]を選択します。

f:id:swx-tamura:20211004104823p:plain

検知した際に利用される EmailアドレスとWebhookのURIを指定出来るので指定します。 今回は、自社のEmailアドレスにしてみました。

下の枠に何のための検知したのか分かるようにコメントを残せるのでよしなに設定し、[Create my Canarytoken] を押下します。

f:id:swx-tamura:20211004104905p:plain

以下画面のようにクレデンシャルが表示されます。
ちなみに、outputと region は特に気にしなくて問題ありません。

f:id:swx-tamura:20211004104929p:plain

セキュリティリテラシーの高い方は、慎重に取り扱うべきクレデンシャルがいきなりモザイクもなく描画されてびっくりしたと思います。 (一応ここの画面にはモザイクはかけておきますけど実際にはかかっていません)

これがCanaryTokenとなり、以下のような特徴を持つ謂わば囮のような役割をする物となります。

  • IAMアクセスキーとしては有効で対となるシークレットアクセスキーを使えば認証が可能
  • 権限(IAMポリシー)は何も付与されておらず、認証を通過してもそのAWS環境に対して何も出来ない
  • 認証が行われた際に、CanaryTokenの管理者がそれを検知出来る仕組みを有する

早速、発行されたCanaryToken (アクセスキーとシークレットアクセスキー) を使ってアクセス出来ない環境へアクセスしてみます。今回はワンライナー(AWS CLI)で以下のように適当に突っついてみました。(XXXの箇所は手動モザイクです)

% date;AWS_ACCESS_KEY_ID=XXXXXXXXXXXXXXXXXXX AWS_SECRET_ACCESS_KEY=YYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYY aws2 s3 ls
Mon Oct  4 10:46:06 JST 2021

An error occurred (AccessDenied) when calling the ListBuckets operation: Access Denied
%

AWS CLI のコマンドは、有効なものであれば何でも良いです。 (基本的にクレデンシャルで認証が通って、Access Denied が出ればOKです)

指定したEmailアドレス宛に通知されます。

  • From:noreply@canarytokens.org
  • Subject:Your Canarytoken was Triggered

中身を見ると、アラートとして悪意のあるユーザー(今回は、s3 lsをした私) の情報が表示されます。 このように実行した悪意のあるユーザーの大まかな経路特定に役立つ情報も添えられています。

f:id:swx-tamura:20211004105417p:plain

More info on this token を押下するとアクセス元がざっくり地図でも確認出来ます。

f:id:swx-tamura:20211004125006p:plain

悪意のある私が東京からアクセスした事がバレてしまいました。
どのAS番号のどのホスト経由などの情報程度であれば確認が出来ます。また、複数回実行すると履歴が残ります。

無料の canarytokens.org 利用の場合は、実際にどのようなAPIが叩かれたのか？の情報までは得られないようです。

本当に悪意のある人へ情報が漏れれば「s3 ls」単発なんて生ぬるいものだけで済む訳はありません。

スクリプトキディがするような悪戯であれば稼働しているEC2インスタンスにTerminateを試みたり ほんまもんのクラッカーであれば、金になる機密情報の搾取を試みたり仮想通貨のマイニングに利用したりする為に、様々なAPIが叩かれる事が想定されるので、設定してあれば大量の通知が受け取れ異常に気がつけると思われます。

活用方法の例

canarytokens.org に、使い方のアイディアとして画面に書かれていたものを紹介しますが

macOSやLinuxをご利用の場合、大抵の方は ~/.aws/credentials に当情報を記載し管理されている事と思いますが、ここに敢えて CanaryToken の情報を記載して仕掛けてみるという内容です。

もし、何らかのセキュリティ事故でローカルの ~/.aws/credentials 情報が漏洩した場合、 情報を引き抜いた悪意のあるユーザーは記載されているクレデンシャルの情報を順に総当りしたりし、お目当てのアクションが出来るか模索してくる筈です。

その際、CanaryTokenが突っつかれれば情報流出や悪意のある内部ユーザーがいる可能性がある事を検知できます。

ちなみに今回のCanaryTokenとは別の観点でのお話ですが、この様なケースで実際に被害を受けない為にもMFAは設定しておきましょう。

ざっくり CanaryToken について理解できたところで canarytokens.org と同じ様な仕組みを実際に運用しているAWSアカウントにて作成していきます。

管理対象AWSアカウントに設定すると何が良いのか？

　上で紹介した危険の前兆を検知するというセキュリティレイヤーを新たに構築出来る点以外で考えると、叩かれたAPIに関するより詳細な情報が得られる事に加え以下2点あります。

NIST準拠

NIST (National Institute of Standards and Technology)というアメリカ政府が定めるセキュリティ基準への準拠できるとの事でコンプライアンスの観点でのメリットがありそうです。

  • NIST 800-5 (rev.4)

CSPM製品のルール準拠

Cloud Security Posture Management(CSPM)のようなセキュリティ製品では、上のNISTのようなセキュリティ基準や AWS Well-Architected のようなフレームワークへの準拠を目指す為に構成されていますので当然その類のルールを持ち、評価に利用されているのでそのルールに対する準拠出来る点でメリットがありそうです。

例としてCSPM製品の代表として、Trend Micro Cloud One Conformity 製品 (以後C1C)の内容を紹介すると、以下のようなルールがあり概要と対処方法が紹介されています。

www.trendmicro.com

ざっくり和訳かつ要約すると

「先を見越したセキュリティ防御を実装するために、AWSアカウント内にCanaryTokensとして1つのIAMユーザーが作成されていることを確認してください」とあります。

「ここに仕掛けよ」とまでは明記/指示はされていませんがWebアプリケーション、コードのリポジトリ、EC2インスタンス等に仕掛ける事で追加の保護レイヤーを提供できるといった記載があります。

AWSのアクセスキーは、昔から悪意のある攻撃者視点だと大変魅力的なもので、実際AWSのセキュリティ事故でもかなりの割合を占めていると推察されます。

なのでC1Cでは、CanaryTokenを持つIAMユーザー(CanaryUser的なもの) の作成を推奨し、もしそのIAMユーザーの設定に異変があった場合には、リスクレベル Very High として検知する挙動をするのがデフォルトとなっています。

もちろん、製品が定めている対応やら警戒レベルの設定やらが必ずしも正解という訳ではありません が、 CanaryTokenを仕掛け、その仕掛けに異常がない事を継続監視してセキュリティリスクに備えましょうといった一つの考え方があるとご理解頂ければと思います。

実際にやってみる

　今回は、自分のAWS検証環境にてGUI(AWSマネジメントコンソール)でIAM, AWS CloudTrail , Amazon CloudWatch , Amazon SNS を駆使しながら作っていきます。

よくある内容かつ、基本的なサービスばかりなので細かい操作オペレーションは割愛します。

IAMユーザーの作成

CanaryToken専用 として、IAMユーザーを1つ作成していきます。

(参考) CanaryTokenで利用するIAMユーザー名やProfile名に関する考察

悪意のあるアプリケーション(ツール)の侵入によりアクセスキーが収集され攻撃されるケースなら該当しないかもしれませんが、人間のクラッカー(または内部不正者)がIAMをDescribe出来る状況まで侵入されている状態まで想定すると、少なくても Canary といった文字列のような明らかにクラッカー視点で罠だと警戒されるような文字列は入っていない方が良いようにも感じます。

具体的に、IAMユーザーの一覧はもちろん、アクセスキーの項目でも仮に以下のように設定されていたら、不正プログラムの侵入ではなく悪意のある人間の行動であれば「このキーは手を出さんとこ...」って思うような気がします。(釣り針が大きすぎるという事です)

[CanaryToken]
aws_access_key_id = XXXXXXXXXXXXXXXXXXXXX
aws_secret_access_key = YYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYY

[SystemA-RO]
aws_access_key_id = XXXXXXXXXXXXXXXXXXXXX
aws_secret_access_key = YYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYY

なので環境にもよるでしょうが、既存のIAMユーザー名やProfile名に近い形で設定するのが良いかもしれません。勿論、紛らわしい分、社内の管理メンバーには周知は必要と思われますが。

(ここは自信がないので、専門家の方いらっしゃいましたらコメント頂けると大変助かります)

今回はIAMユーザー名にCanaryという単語を入れると警戒されそうなのでとりあえず Hayabusa にしてみました（）。

CanaryToken専用のIAMユーザーとなるので、「アクセスキー - プログラムによるアクセス」のみを許可する形で作成します。

f:id:swx-tamura:20211004110630p:plain

付与するIAMポリシー選択画面では何も付与せず 進みます。 (ここが通常のIAMユーザーと考え方が異なるので大切なポイントです)

f:id:swx-tamura:20211004110837p:plain

アクセスキーが1つ発行されるので、情報を控えておきます。
CanaryTokenに相当するこちらのクレデンシャルはダウンロードして保管し管理者のメンバーやらセキュリティチームで共有しておくと良いかもしれません。

Amazon SNS のトピック作成

CanaryTokenが検知された際の通知で利用する為にスタンダードのトピックを1つ作成します。

f:id:swx-tamura:20211004111135p:plain

トピックにサブスクリプションを設定していきます。

今回は例として自分のEmailアドレスへの通知となりますが、AWSアカウント管理者やらセキュリティ組織が検知しやすい形で設計する事が大切です。(WebHookでSlackの好ましいチャンネルに飛ばす等)

f:id:swx-tamura:20211004111240p:plain

SNSサブスクリプションを承認します。(以下blogエントリー参照)

blog.serverworks.co.jp

Amazon CloudWatch にて対象ログにメトリクスフィルターを作成

Amazon CloudWatch の ロググループより AWS CloudTrail で取得しているAPIのロググループを選択し、メトリクスフィルターを作成していきます。

フィルタパターンには以下内容を指定します。 (XXXにはCanaryTokenのアクセスキーを指定)

{$ .userIdentity.accessKeyId = "XXXXXXXXXXXXXXXXXXXX"}

以下のように通常の何もない時は「0」、CanaryTokenのアクセスキーで認証が通過した際にはフィルターにマッチするログが出力され「1」となるように設定していきます。

f:id:swx-tamura:20211004130534p:plain

アラームの作成

続けて Amazon CloudWatch 左ペインのアラームよりアラームを新規作成していきます。

統計を最大値にし、上のメトリクスフィルターで「1」となった際に検知して通知出来るよう 最大値を is >= 1 として設定して設定しています。

f:id:swx-tamura:20211004113912p:plain

これで設定は完了です。

動作を確認する

上で試した内容と同様ですが AWS CLI で悪意があるユーザーのつもりで突っついてみます。

% date;AWS_ACCESS_KEY_ID=XXXXXXXXXXXXXXXXXX AWS_SECRET_ACCESS_KEY=YYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYY aws2 s3 ls
Mon Oct  4 12:09:25 JST 2021

An error occurred (AccessDenied) when calling the ListBuckets operation: Access Denied
%

しばらくすると仕掛けたアラームが発火します。

f:id:swx-tamura:20211004121321p:plain

アラームの通知内容を確認する

一般的なアラームの内容となりますが、Emailの通知設定の場合は以下のような内容で通知がされました。

  • From: no-reply@sns.amazonaws.com
  • Subject: ALARM: "hayabusa-alarm" in Asia Pacific (Tokyo)

f:id:swx-tamura:20211004121544p:plain

実際に叩かれたAPIの確認

無料の canarytokens.org では叩かれたAPIまでは確認できませんでしたが、今回は自分のAWSアカウントで仕掛けたものなのでAWS CloudTrail のAPIログから詳細を追う事が可能です。

CloudWatch Logs Insights にて 以下のようにアクセスキーでフィルタして抽出するのが便利です。 (XXXにはCanaryTokenのアクセスキーを指定)

fields @timestamp, @message
| filter userIdentity.accessKeyId = "XXXXXXXXXXXXXXXXXXX"

f:id:swx-tamura:20211004131523p:plain

このように悪意のある私がどのようなオペレーションをしたか丸裸です。

CanaryTokenを設置する

あとは CanaryTokenを必要な場所に設置していきます。

これは環境によるところなので、上に記載したような活用例や世の中の活用事例を参考にしながら、AWS環境を熟知している方とセキュリティに知見のある方で検討して対応を進めると良いでしょう。

まとめ

　あなたのAWS環境のカナリアが鳴き止まない事を祈りつつも、鳴き止んだ(検知した)際には、すぐさま有るべき行動を取れるようにしたいものです。

もし、それが古い映画とかで登場する「本当の炭鉱のカナリア」であれば、その場からすぐさま避難するというシンプルかつ誰でも本能的に取れる行動でしたが、現代のパブリッククラウド環境でその状況に立ち会った際は、ただ退避するというのは悪手でしかなく、戦慄が走っている状況でそれに立ち向かい対応をしていかなければなりません。

アクションプランも合わせて検討して備えておきたいものです。