3 Top IoT “security” Architectures and How to Fix Them
Properties1
description
이 문서는 필자가 현장에서 접한 대표적인 IoT 보안 아키텍처의 오해와 한계를 지적하며, 진정한 보안을 위한 개선 방안을 제시한다. 필자는 완벽한 IoT 보안 아키텍처는 존재하지 않으며, ENISA 보고서 등 다양한 접근이 있음을 전제한다. 특히 'HTTPS만 있으면 보안이 된다'는 잘못된 인식(3 번째 아키텍처)을 비판하며, HTTPS는 IP 통신 경로만 보호할 뿐 저장된 데이터, BLE/ZigBee 같은 비-IP 프로토콜…
10 min read
3 Top IoT “security” Architectures and How to Fix Them
Source
Evernote/Inbox/3 Top IoT “security” Architectures and How to Fix Them.md
Summary
이 문서는 필자가 현장에서 접한 대표적인 IoT 보안 아키텍처의 오해와 한계를 지적하며, 진정한 보안을 위한 개선 방안을 제시한다. 필자는 완벽한 IoT 보안 아키텍처는 존재하지 않으며, ENISA 보고서 등 다양한 접근이 있음을 전제한다. 특히 ‘HTTPS만 있으면 보안이 된다’는 잘못된 인식(3 번째 아키텍처)을 비판하며, HTTPS는 IP 통신 경로만 보호할 뿐 저장된 데이터, BLE/ZigBee 같은 비-IP 프로토콜, 디버그 포트(JTAG 등)는 보호하지 못함을 강조한다. 공격자는 HTTPS 대신 취약한 BLE 통신이나 게이트웨이/센서 내부의 자격 증명을 노릴 수 있으므로, 모든 엔드포인트의 데이터 암호화, 비-IP 통신의 적절한 보안 적용, 하드웨어 인터페이스 보호가 필요함을 주장한다.
Key Points
완벽한 IoT 보안 아키텍처는 존재하지 않으며, 특정 공격에 대한 방어 가능성은 증명할 수 있으나 모든 공격을 예측했다고 증명할 수는 없다.
현장에서는 HTTPS 사용만으로 보안을 충족한다고 생각하는 경우가 많으나, 이는 통신 경로만 보호할 뿐 저장 데이터나 로컬 통신(예: BLE)은 보호하지 못한다.
공격자는 HTTPS 암호화 대신 BLE 중간자 공격, 게이트웨이/센서 메모리 내 자격 증명 탈취, unprotected JTAG/디버그 포트 등을 통해 시스템을 침투할 수 있다.
개선 방안: 모든 엔드포인트의 저장 데이터 암호화, BLE/ZigBee 등 비-IP 통신 프로토콜의 기본 보안 기능 활용 또는 전문가 상담, 하드웨어 디버그 인터페이스 보호.