この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
この記事の趣旨
本企画は、弊社チームIoTメンバーが初心に返ってIoTサービスについて学びなおし、解説してみようというものです。本エントリーでは「デバイスやクラウド側のセキュリティ監査と見つかった問題の軽減を行う」機能である「AWS IoT Device Defender（以後、Device Defender と表記）」について紹介します。
この記事の前提
この記事ではいくつか実際の機能を試してみた内容を含んでいます。この内容は公開されている下記のワークショップの内容になります。ワークショップを実施していなくても理解いただけるように記載したつもりですが、ワークショップの内容はとても分かりやすいので、ぜひ一度試していただければと思います。
AWS IoT Device Defender とは？
一言で言えば、クラウド側の設定やデバイスの挙動に対してセキュリティチェックを行い問題があれば軽減してくれるマネージドサービスです。
セキュリティの観点からクラウド側の設定を定期的に監査したり、デバイスの挙動を監視して異常動作を検出することができます。また検知した問題に対して自動でリスクが無い状態へ変更することも可能です。
具体的には次のようなことができます。
- クラウド側のセキュリティ設定の監査
- 例1：証明書のポリシーに過剰な権限が付与されていないかチェック
- 例2：証明書の有効期限が切れていないかチェック
- デバイス側の不正な異常動作の検出
- 例1：不要なポートを Listen していないかチェック
- 例2：想定外のトラフィックが出ていないかチェック
また、これらのチェックで異常を検知した場合は「軽減アクション」として、問題となっている設定を自動的に変更してリスクを軽減（緩和）することも可能です。例えば、証明書の有効期限が切れていれば「古い証明書をデタッチして新しい証明書を発行・アタッチし直す」といった事が自動でできるようになります。
このようにセキュリティの観点から、クラウドの設定やデバイスの挙動を継続的に監視して、問題があれば事前に定義した内容にて軽減アクションで脆弱性を解消することができます。
クラウド側のセキュリティ監査
繰り返しになりますが、クラウド側のチェックには、デバイスに付与する IoT ポリシーの権限チェックや、デバイス証明書の有効期限のチェック、デバイス証明書の共有などがチェックされます。
例えば、とあるデバイスの IoT ポリシーに過剰な権限が付与されていれば、デバイスを悪用された時に問題となるので、権限内容が適切かどうかをチェックすることができます。
これらのチェックは AWS によって事前定義された項目に対して実施されます。事前定義されたチェック内容は下記のとおりです。
- CA 証明書が取り消されたがデバイス証明書がまだアクティブ
- 共有されたデバイス証明書
- デバイス証明書のキー品質
- CA 証明書キーの品質
- Cognito の Unauthenticated role の権限が過剰
- Cognito の Authenticated role の権限が過剰
- AWS IoT ポリシー権限が過剰
- ロールエイリアス の権限が過剰
- ロールエイリアスにより過去1年間で未使用のサービスに対する権限
- CA 証明書の有効期限切れ
- MQTT クライアント ID の競合
- デバイス証明書の有効期限切れ
- 取り消されたデバイス証明書がまだアクティブ
- ロギングが無効
全ての項目でチェックしたり、必要な項目だけでチェックすることも可能です。
また、これらのチェック項目には問題の深刻度として「クリティカル」「高」「中」「低」と4つのレベルが定義されています。
スケジューリング
クラウド側の監査の実行タイミングは、次のように設定することができます。
- 毎日
- 毎週/隔週で特定曜日
- 月末・月初・特定日（毎月16日）
- 設定しない（手動で都度実行）
決まった時間で定期的に監査を行うことで継続的に健全なセキュリティレベルを維持します。
なお、初期状態でオンデマンドチェックを試した所、完了までに1時間ほどかかったのでチェックをスタートしたら気長に待ちましょう。
軽減アクション（ Mitigation actions ）
先程記載した「セキュリティ監査の一覧」の中から監査を実行した結果、セキュリティ上の問題があればその問題を軽減（緩和）するためのアクションを実行することができます。
これを「 Mitigation action 」 と呼びます。ドキュメントやコンソール上では「緩和アクション」や「軽減アクション」と表現 されます。
この軽減アクションでは、実行したチェックの内容に応じて AWS で事前登録したアクションを実行することができます。
例えば、「過剰な権限を持ったポリシーを見つける」チェック項目の場合は、「権限をデフォルトポリシーに変更する軽減アクション」を実行する ことができます。
具体的な画面を見てみましょう。最初に軽減アクションを作成しておきます。コンソールの場合は IoT Core のメニュー画面から「軽減アクション」の画面を開き「作成」をクリックします。
適当なアクション名を入力します。アクションタイプとして今回は「デフォルトのポリシーバージョンを置き換え（軽減の監査のみ）」 を選択します。（このアクションタイプは対象のポリシーを無害なポリシーに変更するものです。）
最後に、必要な IAM Role をセットして保存します。
次の画面は監査を実行した結果です。過剰な権限を持ったポリシーが2件見つかっていることが分かります。
この問題に対して緩和アクションを設定してみます。今回は2つのポリシーで問題が見つかっていますが、「ThingOne-Policy」 というポリシーに緩和アクションを設定していきます。
緩和アクションを実行するタスクに名前を付けて、緩和アクションの種類を選択します。ここでは先ほど作成した「Empty_Policy」 を選択します。
ここで複数の軽減アクションを選択して実行する事もできます。
次の画面で「確認」 をクリックすると軽減アクションが実行されます。
軽減アクションが完了するまで待機します。
完了したら結果を確認します。アクションが「成功」していることが分かりました。次に具体的にポリシーがどのように変更されたのか確認します。
アクションの結果を確認する前に、以前のポリシー内容を確認しておきましょう。アクションの実行前は下記のように過剰な権限を付与されていることが分かります。ここでバージョンが「バージョン2」 であることに注目してください。
次の画面は軽減アクションを実行した後の画面です。新しく「バージョン3」としてポリシーが更新されていることが分かります。また、ポリシーの内容も更新されて何も権限が無いことが分かります。
その他の監査結果と実行できるアクションの対応については、下記に一覧が記載されていますので詳細はドキュメントを参照いただければと思います。
デバイスの振る舞いチェック（ AWS IoT Device Defender Detect ）
次にデバイス側のチェック内容について見ていきましょう。Device Defender ではデバイスの動作を監視して異常な動作を検出することもできます。これはAWS IoT Device Defender Detect と呼ばれます。
デバイスのチェックでは2種類のメトリクスでチェック内容を定義することができます。
- クラウド側のメトリクス
- デバイス側のメトリクス
クラウド側のメトリクス
クラウド側では「デバイスから届くメッセージサイズ」や「デバイスからクラウドへ接続する際の認証エラーの回数」などから、そのふるまいが異常かどうか判断されます。判断する基準は事前に設定します。（後述しますが機械学習で判断することも可能です）
デバイス側のメトリクス
デバイス側では、「想定外のポートでリッスンしていないか」「デバイスから想定外のサイズのパケットが出ていないか」といった振る舞いをメトリクスとして AWS に送信してチェックすることができます。
メトリクスを収集して送るためには、デバイス上でエージェントを動かす必要があります。エージェントには「AWS IoT デバイスクライアント」 を利用するのが簡単でお勧めです。
「AWS IoT デバイスクライアント」を使うことでデバイス側のメトリクスを取得してAWS IoT Core へ送ることができます。
メトリクスには「アウトバウンドのバイト数」や「Listen しているポート数」など複数種類が用意されています。 全ての種類については下記ドキュメントで確認することができます。
デバイスにエージェントを入れることが難しい場合は、クラウド側のメトリクスだけでチェックを実行することもできます。
クラウド側とデバイス側それぞれのメトリクスの種類については、下記ドキュメントが参考になります。
デバイス側の問題の修正
Device Defender Detect で検出された問題を修正する場合、Device Defender 単体の機能としては提供されていませんが、AWS IoT Management のジョブ機能を使って修正することができます。
AWS IoT Management の詳細については本記事では触れませんが、流れとしては下記のようになります。
- 検出した内容に対するジョブを登録する
- ジョブドキュメントの作成など
- ジョブを実行してデバイス側でジョブを受け取る
- ジョブの内容から然るべき処理をデバイス側で実行する
- 問題が解消する
（ジョブを受け取った）デバイスで実行する処理はデバイスに依存するためユーザー側で実装する必要があります。これは単独で IoT Management のジョブ機能を利用する場合も同様です。（別の表現をするならば「問題の修正のためにジョブ機能を使っている」といえます。）
AWS IoT Device Defender Detect を試してみる
それでは下記のような想定を元に、実際にデバイス側の問題の検出と修正について見ていきたいと思います。
正常な動作の定義とチェックの実施
まず最初に正常と想定されるデバイスの挙動を定義する「セキュリティプロファイル」 というものを作成します。
次の画面で「正常な振る舞い」 を設定します。下記の場合は2つの動作を設定しています。この設定以外の動作が検出されると「異常」と見なされます。
- デバイスは TCP 22, 25, 38905 ポートをリッスンしている
- デバイスは 1500 バイト未満のメッセージを送信している
作成したセキュリティプロファイルをどのデバイスに適用するか指定します。
これでセキュリティプロファイルが作成できました。
下記は先程作成したセキュリティプロファイルを開いた画面です。（「動作」 タブ ）
セキュリティプロファイルを作成すると、エージェントからのデータの確認や AWS 側で受け取っているメッセージサイズのチェックなどが実行されます。そのチェックが終わるまで数分待つと、検出された違反をセキュリティプロファイルの「アラーム」タブで確認することができるようになります。
このサンプルデバイスではbadstringtopicというトピックに1500 バイト以上のデータをPublish しているので、下記の画面では Listen しているポートの他に「メッセージサイズ超過」のアラームも検出しています。
なお、メニューの「アラーム」画面からも検出内容を確認することができます。
実際にデバイス側 ( Cloud9 ) のポートの状態を確認すると、たしかに 22, 25, 38905 以外のポート 8888 で Listen していることが分かります。
ちなみに、8888 ポートはサンプルデバイスで意図的に Python スクリプトで Listen させているものになります。 その他のポートは Cloud9 依存のポートになります。
ジョブ機能で異常を修正する
先程デバイス側の問題修正にはジョブ機能を使うことを説明しましたが、ここでもう少し深堀りしていきたいと思います。
なぜジョブ機能を使うのか
通常、デバイス側の環境は様々なので検出した問題を修正するにしても、どのような方法で修正できるのか検討が必要です。
例えば、該当のデバイスで利用できるプログラミング言語、制御方法、OS などが環境やデバイスにより変わるはずです。 そのため、デバイス側の異常の場合は問題を検出したとしても、単一の機能だけで「全てのデバイス」の「全ての問題」を簡単に修正する、なんてことはできません。
そこで、ジョブの機能を使って処理させたい内容をジョブファイルに記載したり、ジョブファイルの中身を読み取って任意の処理を実行させたりすることで、問題の修正を行う事になります。
もちろん、ジョブ機能とは別に既存でデバイス管理システムやメカニズムがあり、そちらでデバイスに何らかの処理を実行できるのであれば、ジョブ機能を使う必要は有りません。既存の仕組みを使って検出した問題を修正する方法でも問題はありません。
ジョブ機能で異常を修正する
今回は、テストとしてジョブ機能を使って問題となっている部分を修正し、アラーム状態を解消するところまで見てみたいと思います。
今回のサンプルデバイスでは、ジョブの通知を受け取ると次の処理を実行するように実装されています。
- 指定のポートの Listen しているプロセスを停止する
- 送信しているメッセージのサイズを小さくする
そのため、このジョブを実行することで検出した問題を修正することができるようになります。
ただ、Device Defender とジョブ機能は直接連携する事はできません。単に検出した問題に合わせてジョブを設定してデバイス側の処理を実装している、と理解いただければと思います。
前置きが長くなりましたがジョブを作成していきましょう。まず最初に「ジョブ」の画面から「ジョブを作成」をクリックします。
次に「カスタムジョブ」を選択します。
ジョブに適当な名前を設定します。
ジョブを実行する対象のデバイスを選択します。今回、このデバイスは「Quarantine_Dynamic」という名前の「ダイナミックデバイスグループ」に所属していたので、それを選択しています。
また、S3にあるジョブファイルのパスも指定します。
ジョブファイルの中身はサンプルなので簡単なものになります。
{
"comment": "This is a job document.",
"task": "example",
"parameters": "none"
}次にジョブの実行タイプを選択します。テストなのでなんでもいいですが、デバイスが「ダイナミックデバイスグループ」に所属していたので、今回は「継続」 を選択しました。
最後に「送信」 をクリックするとジョブが実行されます。
ジョブが作成されて一覧にリストされました。該当のジョブが実行中であることが分かります。
対象のデバイス「ThingOne」に対するジョブの実行が終了しました。
デバイス側で確認してみます。ジョブによりデバイス上で修正処理が実行されて、8888 ポートの Listen がなくなりました。
数分待つと、Device Defender のコンソールでもアラームが解消していることが分かります。
AWS IoT Device Defender Detect で緩和アクションを実行
ここまでの内容で、Device Defender Detect で検知したデバイス側の問題は「ジョブ」機能を使って修正できることを確認しました。
しかし鋭い方は「Device Defender Detect」の画面にも「緩和アクション」のボタンがあることに気が付かれたかもしれません。
「ここで緩和アクションを実行すれば、ジョブ機能を使わなくても検出した問題を修正できるのでは？」と私も一瞬思いました。しかし、デバイス側の問題はデバイスに依存するので AWS 側のボタンひとつで修正できるような夢のようなことはできません。
ここで実行できる「緩和アクション」とは事前に定義したアクションのみです。「クラウド側のセキュリティ監査」 の節で作成した「軽減アクション」を指定することができます。
注意点としては、複数あるアクションタイプの中で、「Device Defender Detect」で実行できるアクションタイプは限定されることです。下記画像では「モノのグループにモノを追加（軽減を監査または検出）」 を選択していますが、「検出」 に対応しているアクションタイプのみ「Device Defender Detect」の緩和アクションに指定することができます。
ここでは「addGroup」 という名前でアクションを作成しました。
この状態で、下記のようにアクションを実行したい問題を指定して「緩和アクションを開始」をクリックします。
実行するアクションを選択する画面が出るので、作成した「addGroup」というアクションを選択して「開始」をクリックするとアクションが開始されます。
これで、対象のデバイスが指定のグループに追加されました。
Device Management のジョブ機能ではグループを指定してジョブを実行することができるので、この緩和アクションを使うことでジョブ機能が使いやすくなります。
余談ですが、今回は「addGroup」のアクションとして「ダイナミックデバイスグループにデバイスを登録」するようにしました。
こうすることでジョブの実行タイプに「継続」を選択すれば、この緩和アクションを実行する度に自動的に「問題を検出したデバイス」に対してのみ問題修正のジョブが継続的に実行されるようになり便利です。
カスタムメトリクス
ここまでは AWS 側で用意されているメトリクスの中から「デバイスの正常な動作」を選択して定義しました。選択肢にはない動作を定義したい場合はカスタムメトリクスとして任意の動作を定義することもできます。
利用する場合は、デバイス側で任意のメトリクスを収集して AWS 側に送信する処理をユーザー側で実装する必要があります。
下記では「AWS IoT Device Defender Agent SDK（Python）」を利用したサンプルエージェントが公開されています。このサンプルでは CPU 使用率をカスタムメトリクスとして利用しています。
CloudWatch との使い分け
カスタムメトリクスというキーワードを見ると CloudWatch を連想しますが、Device Defender はあくまでもセキュリティ監査に特化した機能になります。
そのため、脆弱性を軽減アクションで簡単に緩和できる機能を持っている点や、ジョブ機能との親和性の高さなどが特徴になります。
AWS IoT Device Defender ML Detect
これまではデバイスの異常を検出するために、事前に「正常動作」として想定される挙動を定義していました。しかしデバイスによっては「週末と平日」や「日中と夜間」で動作の傾向が変わることがあります。
このような場合に、機械学習による異常検出を行う事ができます。機械学習によりデバイスの想定される動作を学習して傾向から異常を検出することができるようになります。（今年の3月に GA となった新しい機能です）
ML Detect は機械学習なので、事前に学習に必要なデータを用意しておく必要があります。最低限必要になるのは「過去14日間のメトリックあたり25,000データポイント」になります。
また、カスタムメトリクスは未サポートであったりサポートされていないメトリクスもあるので、利用する場合は下記ドキュメントを一読されることをお勧めします。
最後に
デバイスの監査と一言でいっても内容は多岐にわたります。どこから手を付けていくべきか検討に時間がかかる場合もあると思います。
Device Defender は AWS の IoT サービスを利用することを前提に、多くのユースケースにマッチする監査機能を備えているので、まずは Device Defender から初めてみるというのもいいかと思います。
やや冗長的な説明が続く内容になってしまいましたが、どなたかの一助になれば幸いです。
13
