Amazon Web Services ブログ

AWS IoT Device Defender を使用した IoT ポリシーの設定ミスの検出

はじめに

この度、モノのインターネット (IoT) ポリシーでワイルドカードを使用する際の潜在的な誤設定を特定する新しい AWS IoT Device Defender の監査機能を発表いたしました。 AWS IoT Device Defender は、IoT デバイスのフリートを監査および監視し、IoT 構成を継続的に保護できるフルマネージド型の IoT セキュリティサービスです。意図しないリソースへのアクセスを過渡に許可するようなポリシーなどのセキュリティ上の誤設定は、セキュリティインシデントの主な原因となり、ソリューションのセキュリティ体制を損なう可能性があります。新しい AWS IoT Device Defender の IoT ポリシーの誤設定の可能性の監査機能を使用すると、より簡単に不備を特定し、問題をトラブルシューティングし、必要な是正措置を講じることができます。これにより、IoT ソリューションのセキュリティ体制を向上させることができます。

背景

AWS IoT Core ポリシーは JSON ドキュメントの形式であり、AWS Identity and Access Management (IAM) ポリシーと同じ規則に従っています。 AWS IoT Core ポリシーを使用すると、AWS IoT Core データプレーンへのアクセスを制御できます。 AWS IoT Core データプレーンは、 AWS IoT Core メッセージブローカーへの接続と MQTT メッセージの送受信を可能にするオペレーションで構成されています。同様に、データプレーンオペレーションは、AWS IoT Device Shadow を介してデバイスの状態を取得または更新するのにも役立ちます。 AWS IoT Device Shadow は、デバイスが AWS IoT に接続されているかどうかに関係なく、デバイスの状態をアプリや他のサービスで利用できるようにする AWS IoT Core の機能です。

IoT ポリシーのワイルドカードと MQTT のワイルドカードとを混同することで、IoT ポリシーを誤って設定してしまう場合があります。もし、お客様がこのような方法で IoT ポリシーを設定すると、デバイスが明示的にサブスクリプションを拒否されるべきであるにもかかわらず、トピックに関するデータを受信するために過渡にサブスクライブすることが可能になってしまいます。

このブログでは、2 種類の誤設定を題材として、 AWS IoT Device Defender の監査機能を使用して、 IoT ポリシーの潜在的な誤設定を特定して修正する方法について説明します。

MQTT と AWS IoT Core ポリシーにおけるワイルドカード文字の使用

MQTT と AWS IoT Core ポリシーとでは、ワイルドカード文字が異なるため、慎重に検討した上で選択する必要があります。 MQTT では、ワイルドカード文字「+」および「#」は、複数のトピック名をサブスクライブするために MQTT トピックフィルターで使用されます。単一の MQTT トピックレベルには文字「+」を、複数の MQTT トピックレベルには「#」を使用します。一方、 AWS IoT Core ポリシーでは、ワイルドカード文字として「*」と「?」を使用し、 IAM ポリシーの規則に従います。ポリシードキュメントでは、「*」は任意の文字の組み合わせを表し、疑問符「?」は任意の 1 文字を表します。

ポリシードキュメントでは、 MQTT におけるワイルドカード文字である「+」と「#」は、特別な意味を持たない文字として扱われます。ポリシーのリソース属性に複数のトピック名やトピックフィルターを記述するには、 MQTT におけるワイルドカード文字である「+」や「#」の代わりにワイルドカード文字「*」と「?」を使用します。

ポリシードキュメントで使用するワイルドカード文字を選択する場合には、 MQTT トピックフィルターの「+」文字のように、「*」文字は単一のトピックレベルに限定されないことに注意してください。ワイルドカードの指定を単一の MQTT トピックフィルターレベルに制限するために、複数の「?」文字の使用を検討してください。MQTT および MQTT クライアントの AWS IoT Core ポリシーで使用されるワイルドカード文字の例については、ドキュメントを参照してください。

誤設定には2種類あります。

タイプ1: トピック空間「building/*」全体のメッセージを受信し、「buiding/control_room/*」に関連する特定のサブトピックのメッセージは受信しないようにしたい場合

この例では、トピックフィルターではアクセスを拒否することを意図していますが、ワイルドカードの使用により、結果的にアクセスが許可されてしまいます。許可ステートメントにワイルドカードを使用したトピックフィルターと、許可リソースのサブセットを含む拒否ステートメントとを含むポリシーでは、ワイルドカード文字をサブスクライブすることで拒否されるべきトピックのメッセージにアクセスできる可能性があります。

{
Effect: Allow
Action: Subscribe
Resource: /topicfilter/building/*

Effect: Deny
Action: Subscribe
Resource: /topicfilter/building/control_room/#

Effect: Allow
Action: Receive
Resource: /topics/building/*
}

実際に、デバイスが「building/#」をサブスクライブすると、「building/control_room/3」からメッセージを取得できてしまいます。

これは、トピック「building/#」が「building/*」の許可ステートメントに合致し、デバイスのサブスクライブが認可されるためです。アプリケーションコードの下部では「building/#」はすべてのデータに合致し、デバイスが既にサブスクライブしていれば、合致するすべてのトピックのデータを受信することに注意してください。

AWS IoT Core ポリシーで MQTT クライアントのトピックフィルターを指定する場合には、 MQTT のワイルドカード文字「+」と「#」はリテラル文字列として扱われます。これらを使用すると、意図しない動作が発生する可能性があります。

修正後のポリシーは下記の通りです。

{
Effect: Allow
Action: Subscribe
Resource: /topicfilter/building/*

Effect: Deny
Action: Subscribe
Resource: /topicfilter/building/control_room/*

Effect: Deny
Action: Receive
Not-resource: /topic/building/control_room/*
}

このポリシーにより、デバイスはトピック「/」配下の任意のトピック(例えば、「building/common_area」)にパブリッシュされたメッセージは受信できますが、「building/control_room/」の配下のトピック(例えば、「building/control_room/3」)にパブリッシュされたメッセージは受信できません。

例えば、保守員が特定のスペース(例えば、「/building/control_room/3」)にアクセスすることを許可するために、作成者が意図的に設定するようなユースケースがあるかもしれません。従って、 AWS IoT Device Defender の監査チェックでは、これを潜在的な誤設定と名付け、意図的なものか、または意図しない誤設定なのかの判断はユーザーに委ねています。

タイプ2: トピックスペース「building/camera/*」全体のメッセージをデバイスが受信し、「building/+/control_room」のように control_room を含む特定のサブトピックは受信しないことをお客様が望む場合

MQTT の拒否ステートメントのワイルドカードを特定の文字列で置き換えると、デバイスによって回避される可能性があります。

{
Effect: Deny
Action: Subscribe
Resource: /topicfilter/building/+/control_room

Effect: Allow
Action: Subscribe
Resource: /topicfilter/building/camera/*
}

望ましい動作は、「building/camera/control_room」へのデバイスのアクセスは拒否するが、「building/camera/resident1」へのアクセスは許可することです。

しかし、デバイスはトピック「/building/+/control_room」にリクエストを送信し、トピック「/building/camera/control_room」からのメッセージを受信できてしまいます。

修正方法:

{
Effect: Deny
Action: Subscribe
Resource: /topicfilter/building/*/control_room

Effect: Allow
Action: Subscribe
Resource: /topicfilter/building/camera/*

Effect: Allow
Action: Receive
Resource: /topic/building/camera/*

Effect: Deny
Action: Receive
Resource: /topic/building/*/control_room
}

この修正により、IoT ポリシーは、デバイスが下記のトピックからのメッセージを受信できるようになります。

/building/camera/resident1
/building/camera/resident2
/building/camera/resident3

しかし、下記のトピックからのメッセージは受信できません。

/building/camera1/control_room
/building/camera2/control_room
/building/any_camera/control_room

AWS IoT Device Defender の監査チェックを使った潜在的な誤設定の特定

このセクションでは、前述の 2 種類の誤設定に対して、 AWS IoT コンソールで設定、実行、および修正アクションを行う方法を紹介します。

この例では、次のように AWS IoT にタイプ 1 とタイプ 2 を入力しました。

図1: AWS IoT に設定した MisconfiguredPolicy という名称のタイプ1のポリシー

図2: AWS IoT に設定した MisconfiguredPolicyInfo_2 という名称のタイプ2のポリシー

続いて、新しく追加された「 IoT policy potentially misconfigured 」監査チェックを実行すると、もし AWS IoT ポリシーの誤設定の可能性が見つかった場合には、以下の理由コードが返されます。

a) POLICY_CONTAINS_MQTT_WILDCARDS_IN_DENY_STATEMENT

b) TOPIC_FILTERS_INTENDED_TO_DENY_ALLOWED_USING_WILDCARDS

図3: AWS IoT Device Defender の「 IoT ポリシーの誤設定の可能性」の監査チェック結果

AWS IoT Device Defender の「 IoT ポリシーの誤設定の可能性」のチェックでは、拒否ステートメントに MQTT のワイルドカード文字（「+」または「#」）があるかどうかが検査されます。ワイルドカードは、ポリシードキュメントでリテラル文字列として扱われるため、意図したよりも広い権限が許可される可能性があります。

修正方法

この監査チェックでは、誤検出が発生する可能性があるため、誤設定を含む可能性のあるポリシーにフラグを立てます。今後フラグが立たないようにするためには、監査検出の抑制 を使用して、誤検出をマークします。

また、以下の手順に従って、モノ、モノのグループ、またはその他のエンティティにアタッチされているコンプライアンス違反のポリシーを修正することもできます。

  • CreatePolicyVersion を使用して、新たに準拠したバージョンのポリシーを作成し、setAsDefault フラグを true に設定します（これにより、この新しいバージョンは、ポリシーを使用するすべてのエンティティで有効になります）。
  • V関連するすべてのデバイスが AWS IoT Core に接続できることを確認します。デバイスが接続できない場合には、 SetPolicyVersion を使用してデフォルトポリシーを以前のバージョンにロールバックし、再度ポリシーを修正して、再試行します。

まとめ

この投稿では、 AWS IoT Device Defender 監査を使用して IoT ポリシーの潜在的な誤設定を見つけることについて学びました。「 IoT ポリシーの誤設定の可能性」監査機能は、 IoT ポリシーでのワイルドカードの使用をチェックし、誤設定の可能性がある場合に警告します。次に、セキュリティの推奨事項に従い、必要に応じて是正措置を講じることができます。この新しい監査チェックにより、お客様は IoT ポリシーの誤設定を簡単に減らすことができ、 IoT ソリューションのセキュリティ体制の向上に役立ちます。

AWS IoT Device Defender を使用している場合は、 AWS IoT Device Defender 監査セクションで新しい監査チェックを有効にすることができます。 AWS IoT Device Defender を初めて使用する場合は、 AWS IoT コンソールでワンクリックのプロセスを使用して、 IoT デバイスフリートのセキュリティ体制を向上させることができます。詳細については、 AWS IoT Device Defender のドキュメントを参照してください。

著者

Ryan Dsouza は、 AWS の IoT のプリンシパルソリューションアーキテクトです。ニューヨークを拠点に、 AWS の広範かつ奥深い機能を活用し、より安全でスケーラブルな革新的ソリューションの設計、開発、運用を支援し、測定可能なビジネス成果を実現します。 Ryan は、デジタルプラットフォーム、スマート製造、エネルギー管理、ビルディングおよび産業用オートメーション、 OT/IIoT セキュリティなど、多様な業界において25年以上の経験を積んでいます。 AWS 以前は、 Accenture、SIEMENS、General Electric、IBM、AECOM に勤務し、顧客のデジタル変革の取り組みに貢献しました。

Andre Sacaguti は、 AWS IoT のシニアプロダクトマネージャ-テックです。デバイスメーカー、自動車メーカーなど様々な業界の IoT のお客様が、エッジからクラウドまでデバイスを監視し、セキュリティを確保できるような製品とサービスの開発に注力しています。AWS 以前は、T-Mobile と Qualcomm で IoT 製品を開発し、立ち上げました。

この記事は Identify misconfigured IoT policies using AWS IoT Device Defender の日本語訳です。プロフェッショナルサービス本部 インフラストラクチャアーキテクトの宮本 篤が翻訳しました。