AWS ioT개요

AWS ioT는 Amazone에서 만든 ioT 클라우드 플랫폼이다. 

여러 Device들이 연동이 되어 소통하는 통신 환경이라 할 수 있다. 

구성요소는 위와 같다. 

 

1. 각 Device는 AWS iot플랫폼을 비롯하여 사용할수 있는 기능들에 대한 SDK가 설치되어 있다. 

2. 통신을 위해서는 보안 및 인증을 거치고 디바이스 게이트웨이를 통해 특정 프로토콜을 사용하여 전송이 된다.

3. Rule Engine에서 접근 허용 및 범위를 판단하여 Enforcing 시킨다. 

4. 그리고 밑에 Device shadow한다 => 물리적인 Device를 Software적으로 mapping 한다. 또한 네트워크 단절에도 응답한다고 되어있다. 이는 iot특성상 기존의 연결을 토대로 interaction이 어느 정도 유지된다는 뜻이다. 

AWS iot 게이트웨이 안에는 메시지 Broker가 존재하여 통신 관련 기능을 제공한다. 

앞선 게시물들에서 메시지 Broker에 대해서 애기를 하였는데 pub/sub구조로 동작한다.

위 그림을 보면 Publisher의 topic들을 게이트웨이/Broker가 모아서 Subscriber에게 전송해주는 모습이다.

서버든 Client든 결국 보내는 이가 인증이 되어야 되는데 이것은 역시 인증서 기반으로 이루어진다.

ioT도메인에서는 공개키 인증서와 TLS를 상당히 많이 쓴다고 한다. 

위 그림은 CSR(= Certificate Signing Request)에 대한 설명인데 

Device는 개인키, 공개키가 있으면 공개키를 이용해 적당한 포맷을 만들고 이를 통해 x.509인 증서를 만들어 달라고 CA에게 보낸다.

CA는 자신의 Private key로 서명해서 x.509인증서가 나오게 된다. 

 

이제 AWS ioT인증 과정에 대해 알아보자. 참고로 TLS과정과 상당히 유사하다.

1. Client Hello

2. Server Hello(=인증서 전송, cryptographic method전송)

3. iot client는 서버를 인증하고 신뢰한다.

4-1

1) iot 디바이스는 자신의 인증서를 보낸다.(요청한 경우) 

2) 또한 현재 세션에 대한 해시값을 계산후 비밀키로 서명하여 이것 또한 서비스 서버에 보낸다.

(세션 확인)

4-2 서버는 이를 확인하여 iot를 인증한다.

공통적으로 서버는 인증해야 하고 서버입장에서도 Client를 인증한다.

이까지 인증을 거치면 통신이 되어야 할텐데 그 과정에서 어떤 주체이고 어떤 자원에 접근할 건지가 중요하다.

위 표의 ID를 식별하는 것을 보면 AWS ARN을 쓴다. 

ARN은 AWS Resource Name이다.

하나의 식별자 역할을 하며 각종 접근제어 정책에서 활용되는 것이라고 우선 알고 넘어가고 IAM Role에서 다시 보자.