기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
의 보안 모범 사례 AWS IoT Core
이 섹션에는의 보안 모범 사례에 대한 정보가 포함되어 있습니다 AWS IoT Core. 산업용 IoT 솔루션의 보안 규칙에 대한 자세한 내용은 산업용 IoT 솔루션을 위한 10가지 보안 황금률
에서 MQTT 연결 보호 AWS IoT
AWS IoT Core
디바이스 플릿에서 MQTT 연결 해제의 영향 및 심각도는 여러 요인에 좌우됩니다. 다음이 포함됩니다.
-
사용 사례(예: 디바이스가 보내는 데이터 AWS IoT, 데이터 양 및 데이터가 전송되는 빈도).
-
MQTT 클라이언트 구성(예: 자동 재연결 설정, 연결된 백오프 타이밍, MQTT 영구 세션 사용)
-
디바이스 리소스 제한 사항
-
연결 해제의 근본 원인, 강도 및 지속성
클라이언트 ID 충돌과 잠재적인 부정적인 영향을 방지하려면 각 디바이스 또는 모바일 애플리케이션에 AWS IoT 메시지 브로커에 대한 MQTT 연결에 사용할 수 있는 클라이언트 IDs를 제한하는 AWS IoT 또는 IAM 정책이 있는지 확인합니다. 예를 들어 IAM 정책을 사용하면 이미 사용 중인 클라이언트 ID를 사용하여 디바이스가 의도치 않게 다른 디바이스의 연결을 종료하지 않도록 할 수 있습니다. 자세한 내용은 권한 부여 단원을 참조하십시오.
플릿의 모든 디바이스에는 메시지 게시 또는 특정 범위 및 컨텍스트가 있는 주제 구독과 같은 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 자격 증명을 사용하여 WebSocket 프로토콜을 통해 MQTT에 연결될 때 대체됩니다. AttachThingPrincipal API를 사용하여 인증서 및 인증된 Amazon Cognito 자격 증명을 사물에 연결할 수 있습니다. 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" }
CloudWatch Logs 필터(예: {$.reason= "DUPLICATE_CLIENT_ID" }
)를 사용하여 클라이언트 ID 충돌 인스턴스를 검색하거나 지속적인 모니터링 및 보고를 위해 CloudWatch 지표 필터 및 해당 CloudWatch 경보를 설정할 수 있습니다.
AWS IoT Device Defender
AWS IoT Device Advisor를 사용하여 디바이스가 보안 모범 사례에 안정적으로 연결하고 AWS IoT Core 따를 수 있는지 검증할 수 있습니다.
다음 사항도 참조하세요.
디바이스의 시계를 동기화 상태로 유지
장치에서는 정확한 시간을 유지하는 것이 중요합니다. X.509 인증서에는 만료 날짜와 시간이 있습니다. 장치의 시계는 서버 인증서가 여전히 유효한지 확인하는 데 사용됩니다. 상업용 IoT 디바이스를 제작하는 경우 제품을 판매하기 전에 장기간 보관할 수 있습니다. 이 시간 동안 실시간 시계가 드리프트되고 배터리가 방전될 수 있으므로 출고 시 시간 설정으로는 충분하지 않습니다.
다시 말해 대부분의 시스템에서는 디바이스의 소프트웨어에 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 작업 중 하나는 디바이스에 서버 인증서를 보내는 것입니다. 디바이스는 iot.amazonaws.com
에 연결하는 것을 예상하고 있었는지, 해당 연결이 끝날 때 서버에 해당 도메인에 대한 신뢰할 수 있는 기관의 인증서가 있는지 확인할 수 있습니다.
TLS 인증서는 X.509 형식이며 조직의 이름, 위치, 도메인 이름 및 유효 기간과 같은 다양한 정보가 포함되어 있습니다. 유효 기간은 notBefore
및 notAfter
라는 시간 값 페어로 지정됩니다. 와 같은 서비스는 서버 인증서에 제한된 유효 기간(예: 1년)을 AWS IoT Core 사용하고 이전 인증서가 만료되기 전에 새 인증서를 제공하기 시작합니다.
디바이스별로 단일 자격 증명 사용
클라이언트별로 단일 자격 증명을 사용합니다. 디바이스는 일반적으로 X.509 클라이언트 인증서를 사용합니다. 웹 및 모바일 애플리케이션은 Amazon Cognito 자격 증명을 사용합니다. 이렇게 하면 세분화된 권한을 디바이스에 적용할 수 있습니다.
예를 들어, 전구와 온도 조절기라는 두 가지 스마트 홈 객체에서 상태 업데이트를 받는 휴대폰 디바이스로 구성된 애플리케이션을 가지고 있습니다. 전구는 배터리 수준 상태를 전송하고, 온도 조절기는 온도를 보고하는 메시지를 전송합니다.
AWS IoT 는 디바이스를 개별적으로 인증하고 각 연결을 개별적으로 처리합니다. 권한 부여 정책을 사용하여 세분화된 액세스 제어를 적용할 수 있습니다. 주제 공간에 게시하도록 허용하는 정책을 온도 조절기에 대해 정의할 수 있습니다. 다른 주제 공간에 게시하도록 허용하는 별도의 정책을 전구에 대해 정의할 수 있습니다. 마지막으로 온도 조절기와 전구에 대한 주제에 연결하고 구독하여 이러한 디바이스로에서만 메시지를 수신하도록 허용하는 정책을 모바일 앱에 대해 정의할 수 있습니다.
최소 권한의 원칙을 적용하고 디바이스별 권한을 최대한 좁은 범위로 줄입니다. 모든 디바이스 또는 사용자는에 알려진 클라이언트 ID로만 연결하고 식별되고 고정된 주제 세트를 게시하고 구독할 수 AWS IoT 있는 AWS IoT 정책이 있어야 합니다.
백업 AWS 리전 으로 두 번째 사용
데이터 복사본을 백업 AWS 리전 으로 초 단위로 저장하는 것이 좋습니다. 에 대한 재해 복구 AWS IoT
정시 프로비저닝 사용
각 디바이스를 수동으로 생성하고 프로비저닝하는 것은 시간이 많이 걸릴 수 있습니다.는 디바이스를 처음 연결할 때 프로비저닝할 템플릿을 정의하는 방법을 AWS IoT 제공합니다 AWS IoT. 자세한 내용은 JIT 프로비저닝 단원을 참조하십시오.
AWS IoT Device Advisor 테스트를 실행할 수 있는 권한
다음 정책 템플릿은 AWS IoT Device Advisor 테스트 사례를 실행하는 데 필요한 최소 권한과 IAM 엔터티를 보여줍니다. your-device-role-arn
을 사전 조건에서 생성한 디바이스 역할 Amazon 리소스 이름(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": "*" } ] }
Device Advisor에 대한 교차 서비스 혼동된 대리자 예방
혼동된 대리자 문제는 작업을 수행할 권한이 없는 엔터티가 권한이 더 많은 엔터티에게 작업을 수행하도록 강요할 수 있는 보안 문제입니다. 에서 서비스 AWS간 위장은 혼동된 대리자 문제를 초래할 수 있습니다. 교차 서비스 가장은 한 서비스(호출하는 서비스)가 다른 서비스(호출되는 서비스)를 직접적으로 호출할 때 발생할 수 있습니다. 직접적으로 호출하는 서비스는 다른 고객의 리소스에 대해 액세스 권한이 없는 방식으로 작동하게 권한을 사용하도록 조작될 수 있습니다. 이를 방지하기 위해는 계정의 리소스에 대한 액세스 권한이 부여된 서비스 보안 주체가 있는 모든 서비스에 대한 데이터를 보호하는 데 도움이 되는 도구를 AWS 제공합니다.
Device Advisor가 리소스에 다른 서비스를 제공하는 권한을 제한하려면 리소스 정책에서 aws:SourceArn
및 aws:SourceAccount
글로벌 조건 컨텍스트 키를 사용하는 것이 좋습니다. 두 전역 조건 컨텍스트 키를 모두 사용하는 경우 aws:SourceAccount
값과 aws:SourceArn
값의 계정은 동일한 정책 문에서 사용할 경우 동일한 계정 ID를 사용해야 합니다.
aws:SourceArn
의 값은 스위츠 정의 리소스의 ARN이어야 합니다. 스위트 정의 리소스는 Device Advisor를 사용하여 생성한 테스트 스위트를 나타냅니다.
혼동된 대리인 문제로부터 보호하는 가장 효과적인 방법은 리소스의 전체 ARN이 포함된 aws:SourceArn
글로벌 조건 컨텍스트 키를 사용하는 것입니다. 리소스의 전체 ARN을 모를 경우 또는 여러 리소스를 지정하는 경우, ARN의 알 수 없는 부분에 대해 와일드카드(*
)를 포함한 aws:SourceArn
전역 조건 컨텍스트 키를 사용합니다. 예: arn:aws:iotdeviceadvisor:*:
account-id
:suitedefinition/*
다음 예는 Device Advisor에서 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"
} } } }