본문 바로가기

프로그래밍/IoT

[AWS IoT] IoT Service에서 Policy 사용하기

반응형

2020/05/25 - [프로그래밍/IoT] - [AWS IoT] Policy(정책)_IoT Device와 서버 간의 Interface

 

[AWS IoT] Policy(정책)_IoT Device와 서버 간의 Interface

2번의 포스팅을 통해 IoT Device가 통신을 할 수 있기 위한 IoT 인증서에 대해서 살펴보았다. AWS IoT의 경우, MQTT Protocol에 따라서 통신을 하게 되는데 적절한 인증 방법과 유효한 인증서를 통해 MQTT Bro

jaenjoy.tistory.com

위 글을 통해 IoT Service와 IoT Device가 통신을 할 수 있는 Interface를 정의하는 방법에 대하여 살펴보았다.

그렇다면 실제로 IoT Service를 구축할 때 어떻게 Policy를 사용하는지 간략하게 언급해보고자 한다.

Policy의 영향 범위

1) Policy에 영향을 받기 위한 방법

정상적으로 Cert(인증서)를 받은 Device가 정의된 Interface의 영향을 받으려면 어떻게 해야할까?

즉, IoT Policy의 영향을 받기 위해서는 어떻게 해야되는 것일까?

 

AWS IoT는 2가지 방법을 제공해주고 있다.

첫번째는 인증서에 직접 정책을 연결(Attach)하는 것이다.

두번째는 Static Group에 정책을 연결(Attach)하고, 해당 정책의 영향을 받아야 되는 Thing들을 Static Group에 넣어주는 것이다.

 

첫번째 방법의 경우 AWS Console에서 인증서를 생성할 때, 마지막 옵션으로 정책을 연결할 것인지가 나올 정도니 가장 일반적인 경우이다.

하지만 인증서마다 정책을 연결해줘야 한다면 신규 인증서를 생성할 때 마다 해당 인증서를 사용하는 Thing이 어떤 Inteface를 사용하게 될 것인지 파악하여 적합한 Policy를 연결해줘야 되는 과정이 필요해진다.

즉, 인증서 생성이라는 IoT의 영역과 Interface의 정의라는 Service의 영역이 혼재되는 것이다.

 

두번째 방법은 위의 단점을 해소할 수 있다.

즉, 인증서의 발급 및 생성은 온전한 IoT 영역으로 남겨둔 채 이후 해당 Thing이 사용될 Interface나 특정 Service가 정해지면 해당 Group에 추가하여 Policy의 영향을 받도록 할 수 있다.

하지만 Static Group은 API에서 직접 Group에 Thing을 추가 및 삭제하는 관리가 필요하기 때문에 human error 또는 운영 리소스가 추가적으로 필요해진다.

 

만약 Dynamic Group에 Policy를 Attach할 수 있다면, 위의 단점이 해결될 수 있겠지만 현재 AWS IoT에서는 위의 기능을 제공하지 않는다.

Console의 기준에서는 Dynamic Group에서도 Policy Attach 메뉴가 있었지만, 저장을 누를 경우 4xx 에러와 함께 불가능하다는 메시지가 나온다.

 

2) 동시에 복수의 Policy의 영향을 받을 경우

위에서 간략하게 언급한 두가지 표현(개념)이 있다. IoT의 영Service의 영역

AWS IoT는 개념적으로 본다면 IoT의 영역이며, IoT Platform의 개념에 속한다고 본다.

IoT Service는 Platform에서 제공해주는 기능을 바탕으로 실제 사용자에게 제공할 수 있는 서비스의 구성요소로 만든 것이라 볼 수 있다.

 

모든 IoT 서비스를 제공하는 시스템이 위와 같은 2가지 개념으로 분리되지는 않을테지만,

위와 같은 개념의 분리와 정의가 된다는 것은 하나의 Thing에 대해 2가지 Interface, 즉 Policy가 영향을 미칠 수도 있음을 의미한다.

Platform 영역의 Interface와 Servce영역의 Interface와 같은 2가지 종류로.

 

이처럼 동시에 복수의 Policy의 영향을 받을 경우, Side Effect를 조심해야 되는데

가장 대표적인 Side Effect는 Wild Card " * "의 사용이다.

 

하나의 Thing이 동시에 여러가지 Policy의 영향을 받을 경우, 더 확장된 범위의 Interface에 영향을 받게 된다.

즉, 특정 Policy에서는 publish, subscribe, receive를 개별 topic으로 정의하더라도

다른 Policy의 receive에서 *로 허용한다면, 해당 Thing은 모든 Topic을 수신할 수 있는 것이다.

정의하지도 않았고, 해당 Device가 받을 필요도 없는 정보가 더 많이 전달되는 것이기 때문에 이런 Side Effect를 조심할 필요가 있다.

Policy 작성 시 유의사항

1) Policy의 크기 제한

Policy를 작성할 때의 가장 큰 유의사항은 IoT Limit에 대한 부분이다.

현재 AWS IoT에서는 최대 Policy Document Size를 2048자로 제한하고 있다.

 

연결(Connection), 발송(Publish), 구독(Subscribe), 수신(Receive)의 최소 4가지 항목에 대한 정의를 해야하는데,

2048자로 전체 정책 문서의 크기를 제한하였으니 Policy 작성에 유의해야 한다.

 

위에서 복수의 Policy로 인한 Side Effect를 조심해야 된다는 점을 언급하였지만, 크기 제한이 있기 때문에 적절한 Wild Card를 사용하는 것은 필요하다.

// Do
$aws/things/{thingName}/+/+

// Dont't Do
$aws/things/{thingName}/shaodw/+
$aws/things/{thingName}/jobs/+

예를 들자면 위와 같다.

AWS IoT Reserved Topic 중 shadow와 job에 대한 topic이다.

topic format이 유사하기 때문에 2개를 위와 같이 한줄로 표현하는 것이 Policy를 효율적으로 사용하는 방법이 된다.

 

2) IoT Subscribe Limit

이번에도 IoT Limit에 대한 부분이다.

하지만, Policy 자체에 대한 Limit은 아니다.

 

AWS IoT Core는 하나의 연결당 50개의 Subscribe Topic이 가능하도록 제한을 두고 있다.

즉, 각 Thing당 최대로 구독할 수 있는 Topic은 50개인 것이다.

 

서비스가 고도화되고 복잡해질 수록 사용하게되는 Topic의 종류가 다양해지기 때문에 시작할 때는 Limit에 여유를 두는 것이 중요하다.

따라서 Policy 작업을 할 때는 Subscribe Limit에 따라서 포괄적으로 사용할 수 있는 Subscribe Topic을 만드는 것이 필요하다.

반응형