での MQTT 接続の保護 AWS IoT デバイスのクロックを同期させるサーバー証明書の検証デバイスごとの単一の ID を使用するバックアップ AWS リージョンとして 2 番目のを使用するジャストインタイムプロビジョニングの使用 AWS IoT Device Advisor テストを実行するアクセス許可デバイスアドバイザーのクロスサービスでの混乱した代理の防止

のセキュリティのベストプラクティス AWS IoT Core

このセクションでは、のセキュリティのベストプラクティスについて説明します AWS IoT Core。産業における IoT ソリューションのセキュリティルールについては、「産業における IoT ソリューションにおける 10 のセキュリティゴールデンルール」を参照してください。

での MQTT 接続の保護 AWS IoT

AWS IoT Core は、接続されたデバイスがクラウドアプリケーションやその他のデバイスと簡単かつ安全にやり取りできるようにするマネージド型クラウドサービスです。は、HTTP、WebSocket、および MQTT AWS IoT Core をサポートしています。これは、断続的な接続を許容するように特別に設計された軽量通信プロトコルです。MQTT AWS IoT を使用してに接続する場合は、各接続をクライアント ID と呼ばれる識別子に関連付ける必要があります。MQTT クライアント ID は、MQTT 接続を一意に識別します。別の接続用に既に要求されているクライアント ID を使用して新しい接続が確立された場合、 AWS IoT メッセージブローカーは古い接続を削除して新しい接続を許可します。クライアント IDsは、それぞれ AWS アカウントと内で一意である必要があります AWS リージョン。つまり、の外部 AWS アカウントまたは内のリージョン間でクライアント IDs のグローバル一意性を強制する必要はありません AWS アカウント。

デバイスフリートでの MQTT 接続の中断の影響と重大度は、多くの要因によって異なります。具体的には次のとおりです。

ユースケース (デバイスが送信するデータ、データ AWS IoTの量、データの送信頻度など）。
MQTT クライアント設定 (例えば、自動再接続設定、関連するバックオフタイミング、MQTT 永続セッションの使用など)。
デバイスリソースの制約。
切断の根本原因、その積極性、永続性。

クライアント ID の競合や潜在的な悪影響を回避するには、各デバイスまたはモバイルアプリケーションに、 AWS IoT メッセージブローカーへの MQTT 接続に使用できるクライアント IDs を制限する AWS IoT または IAM ポリシーがあることを確認してください。例えば、IAM ポリシーを使用すると、既に使用中のクライアント ID を使用することによりデバイスが意図せず別のデバイスの接続を閉じないようにすることができます。詳細については、「Authorization」を参照してください。

フリート内のすべてのデバイスには、意図したアクションのみを認可する権限を持つ認証情報が必要です。これには、メッセージの発行や特定のスコープとコンテキストを持つトピックへのサブスクライブなどの AWS IoT MQTT アクションが含まれますが、これらに限定されません。特定のアクセス許可ポリシーは、ユースケースによって異なる場合があります。ビジネス要件とセキュリティ要件に最も合うアクセス許可ポリシーを特定します。

アクセス許可ポリシーの作成と管理を簡素化するために、AWS IoT Core ポリシー変数および IAM ポリシー変数を使用できます。ポリシー変数はポリシーに配置でき、ポリシーが評価されると、変数はデバイスのリクエストから取得された値に置き換えられます。ポリシー変数を使用して、複数のデバイスにアクセス許可を付与する単一のポリシーを作成できます。 AWS IoT メッセージブローカーへの接続に使用される AWS IoT アカウント設定、認証メカニズム、ネットワークプロトコルに基づいて、ユースケースに関連するポリシー変数を特定できます。ただし、最良のアクセス許可ポリシーを記述するには、使用状況と脅威モデルの詳細を考慮してください。

たとえば、デバイスを AWS IoT レジストリに登録した場合、 AWS IoT ポリシーでモノのポリシー変数を使用して、モノの名前、モノのタイプ、モノの属性値などのモノのプロパティに基づいてアクセス許可を付与または拒否できます。モノの名前は、モノの接続時に送信される MQTT 接続メッセージのクライアント ID から取得されます AWS IoT。モノのポリシー変数は、モノが TLS 相互認証を使用して MQTT AWS IoT 経由でに接続するか、認証された Amazon Cognito ID を使用して WebSocket プロトコル経由で MQTT に接続すると置き換えられます。AttachThingPrincipal API を使用して、証明書と認証された Amazon Cognito ID をモノにアタッチできます。iot:Connection.Thing.ThingName は、クライアント ID の制限を適用するために便利なモノのポリシー変数です。次の AWS IoT ポリシー例では、 AWS IoT メッセージブローカーへの MQTT 接続のクライアント ID として登録済みモノの名前を使用する必要があります。


{
	"Version": "2012-10-17",
	"Statement": [
		{
			"Effect": "Allow",
			"Action": "iot:Connect",
			"Resource": [
				"arn:aws:iot:us-east-1:123456789012:client/${iot:Connection.Thing.ThingName}"
			]
		}
	]
}

進行中のクライアント ID の競合を特定する場合は、CloudWatch Logs AWS IoT を有効にして使用できます。クライアント ID の競合が原因で AWS IoT メッセージブローカーが切断する MQTT 接続ごとに、次のようなログレコードが生成されます。


{
    "timestamp": "2019-04-28 22:05:30.105",
    "logLevel": "ERROR",
    "traceId": "02a04a93-0b3a-b608-a27c-1ae8ebdb032a",
    "accountId": "123456789012",
    "status": "Failure",
    "eventType": "Disconnect",
    "protocol": "MQTT",
    "clientId": "clientId01",
    "principalId": "1670fcf6de55adc1930169142405c4a2493d9eb5487127cd0091ca0193a3d3f6",
    "sourceIp": "203.0.113.1",
    "sourcePort": 21335,
    "reason": "DUPLICATE_CLIENT_ID",
    "details": "A new connection was established with the same client ID"
}

{$.reason= "DUPLICATE_CLIENT_ID" } などの CloudWatch Logs フィルターを使用して、クライアント ID が競合するインスタンスを検索したり、CloudWatch メトリクスフィルターおよび対応する CloudWatch アラームを設定して、継続的なモニタリングとレポートを作成したりできます。

AWS IoT Device Defender を使用して、過度に寛容な AWS IoT および IAM ポリシーを特定できます。 AWS IoT Device Defender には、フリート内の複数のデバイスが同じクライアント ID を使用して AWS IoT メッセージブローカーに接続しているかどうかを通知する監査チェックも用意されています。

AWS IoT Device Advisor を使用して、デバイスがに確実に接続 AWS IoT Core し、セキュリティのベストプラクティスに従うことができることを検証できます。

デバイスのクロックを同期させる

デバイスの時刻を正確に保つことが重要です。X.509 証明書には有効期限の日時があります。デバイスのクロックは、サーバー証明書が現在も有効であることを確認するために使用されます。商用 IoT デバイスを構築する場合は、製品が販売される前に長期間保管される可能性があることに注意してください。この間、リアルタイムクロックがドリフトし、電池が放電する可能性があるため、工場での設定時間では不十分です。

ほとんどのシステムでは、デバイスのソフトウェアに Network Time Protocol (NTP) クライアントを含める必要があります。デバイスは、 AWS IoT Coreへの接続を試行する前に、NTP サーバーと同期するまで待機する必要があります。これが不可能な場合は、後続の接続が成功するように、ユーザーがデバイスの時刻を設定する方法を提供する必要があります。

デバイスが NTP サーバーと同期されると、 AWS IoT Coreとの接続を開くことができます。許容されるクロックスキューの量は、接続で何をしようとしているかによって異なります。

サーバー証明書の検証

デバイスが最初に操作するのは、安全な接続を開く AWS IoT ことです。デバイスをに接続するときは AWS IoT、別のサーバーを偽装するのではなく AWS IoT 、と話していることを確認してください AWS IoT。各 AWS IoT サーバーには、iot.amazonaws.comドメイン用に発行された証明書がプロビジョニングされます。この証明書は、ドメインのアイデンティティと所有権を検証した信頼できる認証機関 AWS IoT によってに発行されました。

デバイスが接続するときに最初に AWS IoT Core 行うことの 1 つは、デバイスにサーバー証明書を送信することです。デバイスは、iot.amazonaws.com に接続する予定だったことと、その接続の最後のサーバーが、そのドメインの信頼された機関からの証明書を持っていることを確認できます。

TLS 証明書は X.509 形式で、組織の名前、場所、ドメイン名、有効期間などのさまざまな情報が含まれています。有効期間は、notBefore と notAfter と呼ばれる時間値のペアとして指定されます。などのサービスは、サーバー証明書に限られた有効期間 (1 年など) AWS IoT Core を使用し、古い証明書の有効期限が切れる前に新しい証明書の提供を開始します。

デバイスごとの単一の ID を使用する

クライアントごとに 1 つの ID を使用します。通常、デバイスでは X.509 クライアント証明書が使用されます。ウェブおよびモバイルアプリケーションは Amazon Cognito ID を使用します。これにより、デバイスにきめ細かなアクセス許可を適用できます。

例えば、電球とサーモスタットの 2 つの異なるスマートホームオブジェクトからステータス更新を受け取る携帯電話デバイスで構成されるアプリケーションがあるとします。電球は、バッテリーレベルのステータスを送信し、サーモスタットは温度を報告するメッセージを送信します。

AWS IoT はデバイスを個別に認証し、各接続を個別に処理します。承認ポリシーを使用してきめ細かなアクセス制御を適用できます。サーモスタットのポリシーを定義して、トピックスペースに公開することができます。電球に別のポリシーを定義して、別のトピックスペースに公開することができます。最後に、これらのデバイスからのメッセージを受信するために、サーモスタットと電球のトピックへの接続とサブスクライブのみを許可するモバイルアプリのポリシーを定義できます。

最小権限の原則を適用し、デバイスごとのアクセス許可を可能な限り絞り込みます。すべてのデバイスまたはユーザーには、既知のクライアント ID とのみ接続し、識別された固定されたトピックセットを発行およびサブスクライブ AWS IoT できる AWS IoT ポリシーがに必要です。

バックアップ AWS リージョンとして 2 番目のを使用する

データのコピーをバックアップ AWS リージョンとして 1 秒に保存することを検討してください。Disaster Recovery for AWS IoTという名前の AWS ソリューションは利用できなくなりました。関連付けられた GitHub ライブラリは引き続きアクセスできますが、は 2023 年 7 月に AWS 廃止し、メンテナンスやサポートを提供しなくなりました。独自のソリューションを実装したり、追加のサポートオプションを確認したりするには、「AWSへのお問い合わせ」を参照してください。アカウントに関連付けられている AWS Technical Account Manager がある場合は、その管理者にお問い合わせください。

ジャストインタイムプロビジョニングの使用

各デバイスの手動作成とプロビジョニングには時間がかかる場合があります。 AWS IoT は、最初に接続するときにデバイスをプロビジョニングするテンプレートを定義する方法を提供します AWS IoT。詳細については、「ジャストインタイムプロビジョニング」を参照してください。

AWS IoT Device Advisor テストを実行するアクセス許可

次のポリシーテンプレートは、 AWS IoT Device Advisor テストケースを実行するために必要な最小限のアクセス許可と IAM エンティティを示しています。your-device-role-arn を、前提条件の下で作成したデバイスロール Amazon Resource Name (ARN) に置き換える必要があります。


{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": "iam:PassRole",
            "Resource": "your-device-role-arn",
            "Condition": {
                "StringEquals": {
                    "iam:PassedToService": "iotdeviceadvisor.amazonaws.com"
                }
            }
        },
        {
            "Sid": "VisualEditor1",
            "Effect": "Allow",
            "Action": [
                "execute-api:Invoke*",
                "iam:ListRoles",   // Required to list device roles in the Device Advisor console
                "iot:Connect",  
                "iot:CreateJob",
                "iot:DeleteJob",
                "iot:DescribeCertificate", 
                "iot:DescribeEndpoint",
                "iotjobsdata:DescribeJobExecution",
                "iot:DescribeJob",                                 
                "iot:DescribeThing",
                "iotjobsdata:GetPendingJobExecutions",
                "iot:GetPolicy",
                "iot:ListAttachedPolicies",
                "iot:ListCertificates",
                "iot:ListPrincipalPolicies",
                "iot:ListThingPrincipals",
                "iot:ListThings",
                "iot:Publish",    
                "iotjobsdata:StartNextPendingJobExecution",
                "iotjobsdata:UpdateJobExecution",
                "iot:UpdateThingShadow",                
                "logs:CreateLogGroup",
                "logs:CreateLogStream",
                "logs:DescribeLogGroups",
                "logs:DescribeLogStreams",
                "logs:PutLogEvents",
                "logs:PutRetentionPolicy"
            ],
            "Resource": "*"
        },
        {
            "Sid": "VisualEditor2",
            "Effect": "Allow",
            "Action": "iotdeviceadvisor:*",
            "Resource": "*"
        }
    ]
}

デバイスアドバイザーのクロスサービスでの混乱した代理の防止

混乱した代理問題は、アクションを実行するアクセス許可を持たないエンティティが、より権限のあるエンティティにアクションの実行を強制できるセキュリティ上の問題です。では AWS、サービス間のなりすましにより、混乱した代理問題が発生する可能性があります。サービス間でのなりすましは、1 つのサービス (呼び出し元サービス) が、別のサービス (呼び出し対象サービス) を呼び出すときに発生する可能性があります。呼び出し元サービスは、本来ならアクセスすることが許可されるべきではない方法でその許可を使用して、別のお客様のリソースに対する処理を実行するように操作される場合があります。これを防ぐために、は、アカウント内のリソースへのアクセス権が付与されたサービスプリンシパルを使用して、すべてのサービスのデータを保護するのに役立つツール AWS を提供します。

リソースポリシー内のグローバル条件コンテキストキー aws:SourceArn と aws:SourceAccount を使用して、リソースについてデバイスアドバイザーが別のサービスに付与する許可を制限することをお勧めします。両方のグローバル条件コンテキストキーを同じポリシーステートメントで使用する場合は、aws:SourceAccount 値と、aws:SourceArn 値に含まれるアカウントが、同じアカウント ID を示している必要があります。

aws:SourceArn の値は、スイート定義リソースの ARN である必要があります。スイート定義リソースは、デバイスアドバイザーで作成したテストスイートを指します。

混乱した代理問題から保護するための最も効果的な方法は、リソースの完全な ARN を指定して aws:SourceArn グローバル条件コンテキストキーを使用することです。リソースの完全な ARN が不明な場合や、複数のリソースを指定する場合は、aws:SourceArn グローバルコンテキスト条件キーを使用して、ARN の未知部分をワイルドカード (*) で表します。例えば、arn:aws:iotdeviceadvisor:*:account-id:suitedefinition/*

次の例では、デバイスアドバイザーで aws:SourceArn および aws:SourceAccount グローバル条件コンテキストキーを使用して、混乱した代理問題を回避する方法を示します。


{
  "Version": "2012-10-17",
  "Statement": {
    "Sid": "ConfusedDeputyPreventionExamplePolicy",
    "Effect": "Allow",
    "Principal": {
      "Service": "iotdeviceadvisor.amazonaws.com"
    },
    "Action": "sts:AssumeRole",
    "Condition": {
      "ArnLike": {
        "aws:SourceArn": "arn:aws:iotdeviceadvisor:us-east-1:123456789012:suitedefinition/ygp6rxa3tzvn"
      },
      "StringEquals": {
        "aws:SourceAccount": "123456789012"
      }
    }
  }
}

ブラウザで JavaScript が無効になっているか、使用できません。

AWS ドキュメントを使用するには、JavaScript を有効にする必要があります。手順については、使用するブラウザのヘルプページを参照してください。

ドキュメントの表記規則

セキュリティモニタリング

モニタリング AWS IoT