Google Cloud에서 IoT 백엔드 실행 권장사항

Last reviewed 2024-05-31 UTC

이 문서에서는 Google Cloud에서 사물 인터넷(IoT) 백엔드를 관리하고 실행하기 위한 보안 권장사항을 제공합니다. IoT 솔루션에서 IoT 백엔드는 에지 기기를 다른 리소스에 연결합니다. 이 문서에서는 IoT 백엔드, 즉 메시지 큐 원격 분석 전송(MQTT) 브로커와 IoT 플랫폼에 대해 중점적으로 설명합니다.

이 문서는 Google Cloud의 IoT 아키텍처에 대한 정보와 IoT Core에서 마이그레이션하는 방법에 대한 정보를 제공하는 문서 시리즈의 일부입니다. 이 시리즈의 다른 문서에는 다음이 포함됩니다.

이 문서에서는 기기 사용자 인증 정보를 프로비저닝 및 관리하고 에지 기기를 인증 및 액세스 제어하고 IoT 에지 기기에서 Google Cloud 리소스에 액세스할 수 있도록 허용하기 위한 권장사항을 제공합니다.

IoT 아키텍처

IoT 아키텍처에는 기기 사용자 인증 정보를 프로비저닝 및 관리하고 에지 기기를 인증 및 액세스 제어하고 에지 기기에서 Google Cloud 리소스에 액세스할 수 있도록 허용하는 서비스가 포함됩니다. 이 문서에서는 두 가지 IoT 백엔드 아키텍처, 즉 MQTT 브로커를 사용하는 IoT 백엔드 아키텍처와 IoT 플랫폼을 사용하는 IoT 백엔드 아키텍처에 대해 설명합니다. 이 두 백엔드의 주요 보안 차이는 기기 ID와 기기 관리입니다. IoT 플랫폼은 이러한 기능을 시스템의 일부로 제공하는 반면 MQTT 브로커는 이러한 기능을 제공해야 합니다.

다음 다이어그램은 IoT 아키텍처를 설명합니다.

IoT 백엔드 아키텍처

아키텍처는 다음 세 가지 프로세스에 필요한 서비스를 보여줍니다.

  1. 인증서 프로비저닝: 구성할 에지 기기를 준비하기 위해 완료해야 하는 프로세스입니다.

  2. 인증 및 승인: 에지 기기, MQTT 브로커 또는 IoT 플랫폼이 서로 인증하는 데 사용하는 인증 스키마를 포함합니다.

  3. 에지 기기와 Google Cloud 서비스 간의 연결: 에지 기기가 클라우드 리소스에 연결하고 데이터를 업로드 또는 다운로드하기 위해 완료하는 태스크입니다.

이 문서에서는 주로 프로비저닝 및 인증을 위한 보안 권장사항을 중점적으로 설명합니다.

이 아키텍처에는 다음과 같은 서비스 및 기능 조합이 사용됩니다.

  • 환경 에지에서 배포하고 처리하려는 데이터와 지리적으로 가까운 에지 기기(의료 기기 등). 에지 기기는 IoT 백엔드와 양방향으로 연결됩니다. 즉, IoT 백엔드에서 메시지를 전송 및 수신할 수 있습니다.
  • MQTT 브로커 또는 IoT 플랫폼일 수 있는 IoT 백엔드.
    • MQTT 브로커는 MQTT 프로토콜을 사용하여 연결할 에지 기기에 대한 보안 인터페이스를 제공합니다. MQTT 브로커는 기기 ID 및 기기 관리 기능이 없으며 외부 시스템을 사용하여 이 기능을 제공합니다.
    • IoT 플랫폼은 에지 기기가 연결 및 통신하는 클라우드 애플리케이션입니다. IoT 플랫폼은 MQTT 프로토콜을 사용하여 연결할 에지 기기에 대한 보안 인터페이스를 제공합니다. 각 IoT 플랫폼에는 에지 기기를 인증 및 승인하고 기기 ID를 관리하는 방법을 결정하는 자체 보안 구현이 있습니다.
  • 모든 에지 기기의 인증서를 호스팅하는 중앙 인증서 저장소.
  • 에지 기기에서 액세스해야 하는 클라우드 리소스.

에지 기기 프로비저닝

에지 기기를 백엔드 워크로드와 연결하려면 먼저 에지 기기에 대한 인증서를 프로비저닝해야 합니다. 인증서 프로비저닝 방법을 결정하는 두 가지 주요 시나리오가 있습니다.

  • 솔루션이 상용 일반 기기를 기반으로 하는 경우 기기를 구매한 후 프로비저닝 프로세스를 완전히 제어할 수 있습니다.

  • 커스텀 제작된 기기를 사용하는 경우 기기를 제조하는 동안 초기 프로비저닝 프로세스가 진행되며 공급업체 및 제조업체와 프로비저닝 프로세스를 통합해야 합니다.

어느 시나리오든 루트 인증 기관(CA)에 연결되는 신뢰 체인이 있는 기기 인증서를 만들어야 합니다. 이러한 인증서는 기기 ID를 인증하며 기기에서 수행한 업데이트 및 수정이 신뢰할 수 있는 행위자에 의해 수행되도록 보장합니다. Certificate Authority Service와 같은 CA를 사용하여 다음 태스크를 완료합니다.

기기 인증서를 프로비저닝하려면 다음 태스크를 완료해야 합니다.

  1. 보안 요소(SE) 또는 하드웨어 보안 모듈(HSM)과 같이 기기에서 지원하는 하드웨어 기반 보안 솔루션을 사용하여 공개 키/비공개 키 쌍을 생성합니다. SE 또는 HSM은 비공개 키를 로컬로 저장하고 비공개 키는 외부에 노출되지 않도록 설계됩니다. 하드웨어 기반 보안 솔루션을 사용하여 공개 키/비공개 키 쌍을 생성하지 않는 경우 대신 CA를 사용하여 키를 생성합니다. 자세한 내용은 자동 생성 키 사용을 참조하세요.

  2. 기기 인증서에 서명하고 생성합니다. 공개 키/비공개 키 쌍을 생성한 후 공개 키를 다운로드하고 인증서 서명 요청(CSR)을 만든 다음 서명을 위해 CA에 CSR을 전송합니다. CA는 루트 CA에 연결된 기기 인증서를 생성합니다. 자세한 내용은 CSR 사용을 참조하세요. 자동 생성 키를 사용할 때는 CA에서 직접 기기 인증서를 요청할 수 있습니다.

  3. 에지 기기에 서명된 기기 인증서를 설치하고 Secret Manager와 같은 중앙 인증서 저장소로 인증서를 전송합니다.

자세한 내용은 Google Cloud CA Service를 사용하여 안전하고 안정적인 공개 키 인프라 배포 방법(PDF)을 참조하세요.

기타 프로비저닝 권장사항에 대한 자세한 내용은 에지 및 베어메탈 시스템 및 서버의 자동 프로비저닝 및 구성 권장사항을 참조하세요.

IoT 솔루션 보안을 위해 세 가지 유형의 인증서가 사용됩니다.

  • 루트 CA 인증서는 시스템의 다른 모든 인증서의 신뢰 체인에 대한 루트를 제공합니다. 백엔드 워크로드는 루트 인증서를 사용하여 클라이언트 인증서를 검사하고 에지 기기는 루트 인증서를 사용하여 서버 인증서를 검사합니다. 루트 인증서를 IoT 백엔드와 에지 기기 모두에 배포해야 합니다.

  • 서버 인증서는 IoT 백엔드에 의해 노출되는 엔드포인트를 보호하는 데 사용됩니다. 엔드포인트가 지원해야 하는 다양한 암호화 알고리즘에 대한 서버 인증서가 있습니다. 서버 인증서는 루트 CA에 연결됩니다. Secret Manager는 서버 인증서의 비공개 부문과 공개 부분을 모두 관리하고 저장합니다. 서버 백엔드와 해당 비공개 키로 IoT 백엔드를 구성해야 합니다.

  • 클라이언트 인증서는 에지 기기를 식별하는 데 사용됩니다. 각 에지 기기에는 하나 이상의 클라이언트 인증서가 있습니다. 즉, 보유한 인증서 수가 환경의 에지 기기 수에 따라 증가합니다. 클라이언트 인증서는 루트 CA에 연결됩니다. 클라이언트 인증서를 에지 기기 및 IoT 백엔드에 배포해야 합니다.

HSM 또는 SE를 사용하여 기기 인증서를 생성하는 프로세스

다음 다이어그램은 HSM 또는 SE를 사용할 때 기기 인증서를 프로비저닝하는 방법을 보여줍니다.

기기 인증서를 생성하는 프로세스

이 다이어그램에서는 다음 단계가 수행됩니다.

  1. 에지 기기가 하드웨어에서 공개 키 쌍을 생성합니다.
  2. 공개 키를 다운로드하고 이에 대한 인증서 서명 요청(CSR)을 만듭니다.
  3. CSR을 CA로 전송하여 인증서를 요청합니다.
  4. CA가 다음 작업을 완료합니다.
    1. 인증서에 서명합니다.
    2. 프로비저닝 도구에 기기 인증서를 반환합니다.
  5. 프로비저닝 도구가 다음 작업을 완료합니다.
    1. 인증서를 에지 기기로 보냅니다.
    2. 인증서를 중앙 인증서 저장소에 저장합니다.
  6. 에지 기기가 인증서를 안전한 위치에 저장합니다.

CA를 사용하여 기기 인증서를 생성하는 프로세스

다음 다이어그램은 CA를 사용할 때 기기 인증서를 프로비저닝하는 방법을 보여줍니다.

기기 인증서를 생성하는 프로세스

이 다이어그램에서는 다음 단계가 수행됩니다.

  1. CSR을 생성하고 CA로 전송하여 인증서를 요청합니다.
  2. CA가 다음 작업을 완료합니다.
    1. 공개 키 쌍을 생성하고 공개 키에 서명합니다.
    2. 기기 인증서와 비공개 키를 프로비저닝 도구에 반환합니다.
  3. 다음 작업을 완료합니다.
    1. 인증서와 비공개 키를 에지 기기로 보냅니다.
    2. 인증서와 비공개 키를 중앙 인증서 저장소에 저장합니다.
  4. 에지 기기가 인증서를 안전한 위치에 저장합니다.

기기 ID 권장사항

이 섹션에서는 기기 ID에 대한 권장사항을 설명합니다.

MQTT 브로커와 함께 ID 공급업체 사용

MQTT 브로커는 플러그인, 데이터베이스, 파일에서 제공하는 기기 사용자 인증 정보를 사용하여 에지 기기를 인증합니다. 기기 ID를 체계적이고 확장 가능한 방식으로 관리하려면 ID 공급업체(IdP)를 사용합니다. IdP는 모든 기기의 ID 및 사용자 인증 정보를 관리하며 기기 ID의 기본 정보 소스의 역할을 합니다.

MQTT 브로커에서 기기 ID를 업데이트된 상태로 유지하려면 시스템별 통합 레이어를 구현합니다. 기기 사용자 인증 정보 관리에 대한 자세한 내용은 에지 기기 프로비저닝을 참조하세요.

IoT 플랫폼의 디지털 ID를 정보 소스로 사용

IoT 플랫폼에는 기기 ID와 기기 사용자 인증 정보를 관리하고 플랫폼에 액세스하려는 기기를 인증 및 승인하는 보안 기능이 있습니다. 이러한 보안 기능은 승인된 기기만 IoT 플랫폼에 액세스하도록 허용하고 데이터 무결성을 보장하도록 지원합니다.

IoT 플랫폼에서 관리하는 기기 ID가 IoT 플랫폼이 관리하는 모든 기기의 기본 정보 소스를 나타내는지 확인합니다. 기기 ID 정보가 필요한 IoT 솔루션의 다른 구성요소는 IoT 플랫폼의 보안 시스템을 사용해야 합니다. IoT 플랫폼은 기기에 액세스 권한을 부여하고 IoT 솔루션 전반에서 모든 보안 변경사항을 전파합니다.

네트워크 연결 권장사항

네트워크 연결 보안은 다음과 같은 이유로 중요합니다.

  • 보안 네트워크는 기기가 올바른 백엔드에 연결되도록 보장합니다. 예를 들어 보안 네트워크는 공격자가 제어하는 악성 백엔드에 연결하기 위해 기기를 전환하려고 시도하는 공격인 DNS 스푸핑을 방지할 수 있습니다.
  • 보안 네트워크는 제3자가 데이터 트래픽을 읽을 수 없도록 보장합니다. 예를 들어 보안 네트워크는 공격자가 기기와 백엔드 간의 트래픽을 읽는 중간 공격자 공격을 방지할 수 있습니다.

전송 계층 보안(TLS)을 사용하여 에지 기기와 백엔드 워크로드 간의 네트워크 통신을 보호합니다.

mTLS로 TLS를 확장하여 두 연결 당사자가 서로의 ID를 설정할 수 있는 상호 인증 스키마를 구현합니다.

TLS 사용에 대한 안내는 Google Cloud의 독립형 MQTT 브로커 아키텍처 및 Google Cloud의 IoT 플랫폼 제품 아키텍처를 참조하세요.

MQTT 브로커의 인증서 관리 권장사항

이 섹션에서는 MQTT 브로커를 사용할 때 인증서를 관리하기 위한 권장사항을 설명합니다.

중앙에서 인증서 저장

서버 인증서와 기기 인증서를 중앙 위치에 저장하고 관리합니다. 특히 다음과 같은 관리 기능이 있는지 확인합니다.

  • 모든 기기 및 해당 인증서와 서버 엔드포인트 및 해당 인증서의 인벤토리.
  • 유효성과 같은 인증서에 대한 추가 정보.
  • 기기에서 새 인증서를 사용하여 연결할 수 있도록 기기의 인증서를 추가하고 삭제하는 기능.
  • 백엔드의 다양한 역할이 인증서로 수행할 수 있는 작업을 제한하기 위한 중앙 인증서 저장소에 대한 액세스 권한.

Secret Manager 또는 HashiCorp Vault와 같은 보안 비밀 스토리지와 관리 솔루션을 사용합니다. Secret Manager를 사용하면 기기 사용자 인증 정보의 버전 관리, 업데이트, 무효화를 수행하고 사용자 인증 정보에 대한 액세스 정책을 관리할 수 있습니다.

IoT 플랫폼의 경우 Secret Manager API 액세스를 사용하여 사용자 인증 정보에 대한 액세스를 구현합니다.

에지 기기의 인증서 보호

에지 기기에 인증서와 키를 저장하려면 로컬 신뢰할 수 있는 실행 환경 또는 인증서 저장소를 사용하여 사용자 인증 정보를 보호하고 무단 액세스를 차단합니다. 기기에 보안 비밀 자료를 저장해야 하는 경우 플래시 암호화와 같은 기술을 사용하여 해당 자료를 암호화하고 변조 방지 요소에 저장하여 무단 데이터 추출을 방지합니다.

중앙 인증서 저장소를 MQTT 브로커 인증서 저장소와 동기화

MQTT 브로커는 인증서 기반 인증을 위해 클라이언트 인증서에 액세스해야 하므로 MQTT 브로커의 인증서 저장소를 중앙 인증서 저장소와 동기화해야 합니다. 인증서 추가, 업데이트, 삭제와 같은 중앙 인증서 저장소의 변경사항이 MQTT 브로커 인증서 저장소와 동기화되었는지 확인합니다. MQTT 브로커는 MySQL, PostgresDB, 자바 키 저장소와 같은 인증서 저장소를 사용합니다. MQTT 브로커에서 사용하는 인증서 저장소에 따라 다음 프로세스가 있는지 확인합니다.

  • 중앙 인증서 저장소의 변경사항을 모니터링하고 동기화 프로세스에 알리는 프로세스.
  • 중앙 인증서 저장소에서 변경사항을 적용하고 중앙 인증서 저장소의 변경사항을 MQTT 브로커에서 사용하는 인증서 저장소와 동기화하는 프로세스.

Secret Manager를 인증서 저장소로 사용하면 이벤트 알림을 모니터링 프로세스로 사용할 수 있습니다. 동기화 프로세스를 이벤트 알림의 리스너로 구현할 수 있습니다.

안전하게 에지 기기에 인증서 배포

MQTT 브로커를 사용하는 경우 루트 인증서와 클라이언트 인증서를 에지 기기에 배포합니다. 인증서를 배포할 때는 트래픽을 가로채지 않도록 통신 채널을 보호해야 합니다.

인증서 배포의 주요 통신 채널은 다음과 같습니다.

  • 기존 통신 채널을 통해 IoT 백엔드에서 에지 기기로 연결되는 직접 경로.
  • 에지 기기가 인증서를 요청하고 다운로드하는 간접 경로.

인증서를 배포하는 동안 다음 구성요소가 필요합니다.

  • 인증서 저장소: 인증서를 중앙에서 관리합니다.
  • 배포 조정자: 인증서를 전송하고 각 에지 기기의 배포 프로세스를 추적합니다.
  • 에지 기기의 업데이트 핸들러: 인증서를 수신하거나 다운로드하여 기기에 저장합니다.

에지 기기의 프로비저닝 프로세스 중 인증서를 순환해야 하는 경우 인증서를 배포합니다.

프로비저닝 프로세스 중에 프로비저닝 도구가 SSH와 같은 암호화된 채널을 통해 에지 기기에 직접 액세스하고 SCP와 같은 도구를 사용하는지 확인합니다. 기기가 작동하지 않기 때문에 인증서를 에지 기기에 직접 푸시할 수 있습니다.

인증서를 순환할 때는 배포 조정자 및 에지 기기 간의 통신 채널로 MQTT 브로커를 사용합니다. 다른 채널을 사용하여 인증서를 기기에 다운로드합니다. 작동 중인 에지 기기의 중단을 최소화하려면 간접 인증서 배포 경로를 사용합니다. 이 프로세스는 다음과 같은 논리적 단계로 구성됩니다.

  1. 배포 조정자가 인증서 저장소에서 액세스 사용자 인증 정보를 가져옵니다.
  2. 배포 조정자가 인증서 액세스 사용자 인증 정보를 다운로드 URL과 같은 추가 정보와 함께 에지 기기에 푸시합니다.
  3. 기기 내 업데이트 핸들러가 액세스 사용자 인증 정보를 수신하고 정보를 일시적으로 저장하고 수신을 다시 확인합니다.
  4. 업데이트 핸들러가 기기가 활성 상태가 아닐 때 인증서 다운로드를 조정합니다. 업데이트 핸들러는 액세스 사용자 인증 정보를 사용하여 사용자 인증 정보 저장소에서 인증서를 다운로드합니다.
  5. 인증서를 다운로드한 후 업데이트 핸들러가 인증서 순환 섹션에 설명된 인증서 순환 프로세스를 계속합니다.

Secret Manager를 중앙 인증서 저장소로 사용하는 경우 단기 액세스 토큰을 생성하여 인증서에 대한 액세스 권한을 부여하고 제한할 수 있습니다. 자세한 내용은 안전하게 기기에 액세스 토큰 배포를 참조하세요.

전송 중에 인증서가 노출되지 않도록 방지하려면 에지 기기와 MQTT 브로커 간의 연결을 암호화합니다. 자세한 내용은 네트워크 연결 권장사항을 참조하세요.

자동으로 인증서 순환

노출된 인증서로 인해 발생할 수 있는 손상을 제한하려면 한정된 유효 기간이 있는 인증서를 생성하고 만료되기 전에 인증서를 순환합니다. 대규모 IoT 배포의 경우 자동 인증서 순환 절차를 구현하여 이전 인증서가 만료되기 전에 기기를 새 인증서로 일관되게 업데이트합니다. 유효한 인증서가 없는 기기가 배포되면 기기 작동이 중지될 수 있습니다. 이로 인해 수정 비용이 많이 들고 IoT 솔루션의 전체 기능에 부정적인 영향을 미칠 수 있습니다.

에지 기기는 MQTT 브로커에 메시지를 전송할 수 있고 MQTT 브로커의 메시지를 수신할 수 있도록 MQTT 브로커와 양방향으로 연결되어야 합니다.

인증서를 순환하는 동안 다음 구성요소가 필요합니다.

  • 인증서 인벤토리를 반복적으로 스캔하고 곧 만료되는 인증서를 찾는 모니터링 프로세스. 모니터링 프로세스는 만료되는 인증서에 대한 인증서 순환을 트리거합니다.
  • 인증서 순환을 초기화하고 감독하는 순환 프로세스.
  • MQTT 브로커와 통신하고 기기에서 인증서 순환 단계를 실행하는 에지 기기의 기기 인증서 순환 핸들러.

인증서를 순환하기 위해 IoT 솔루션이 다음 단계를 완료합니다.

  1. 순환 프로세스가 인증서 순환을 시작하기 위해 초기화 메시지를 에지 기기로 전송합니다.
  2. 기기 인증서 순환 핸들러가 순환 작업에 응답을 다시 전송하여 초기화 메시지를 확인합니다.
  3. 순환 프로세스가 CA에서 새 인증서를 요청합니다. 이 요청은 키와 CSR이 MQTT 브로커 메시지로 전송된다는 점을 제외하면 인증서 프로비저닝 요청과 유사합니다.
  4. CA에서 새 인증서를 수신한 후 순환 작업이 중앙 인증서 저장소 및 에지 기기에 인증서를 배포합니다. 또한 MQTT 브로커의 인증서 저장소에 인증서를 동기화합니다.
  5. 기기 인증서 순환 핸들러가 새 인증서를 저장하고 새 인증서를 사용하여 MQTT 브로커와 새 연결을 초기화합니다.
  6. 새 연결이 설정되면 기기 인증서 순환 핸들러가 완료된 메시지를 MQTT 브로커에 전송합니다.
  7. 완료된 메시지가 수신되면 순환 프로세스가 중앙 인증서 저장소의 이전 인증서를 무효화합니다.

순환 프로세스 중에 전송되는 인증서를 보호하려면 인증서 순환에 전용 MQTT 주제를 사용합니다. 이러한 주제에 대한 액세스는 순환 작업 및 에지 기기로만 제한됩니다.

런타임 오류로부터 인증서 순환 프로세스를 보호하려면 변경 및 진행에 지속성을 사용 설정합니다.

Secret Manager를 사용한 보안 비밀 순환에 대한 자세한 내용은 보안 비밀 순환을 참조하세요.

IoT 플랫폼의 인증서 관리 권장사항

IoT 플랫폼을 사용하는 경우 플랫폼에서 제공하는 인증서 업데이트 및 배포 메커니즘을 사용합니다. 백업을 위해 IoT 플랫폼에서 Secret Manager와 같은 보조 보안 비밀 스토리지로 사용자 인증 정보를 정기적으로 내보낼 수 있습니다.

MQTT 브로커를 사용한 인증 권장사항

상호 인증 프로세스 중에 백엔드 워크로드는 에지 기기의 ID를 확인하고 에지 기기는 백엔드 워크로드의 ID를 확인합니다. 백엔드 워크로드가 에지 기기의 ID를 확인하면 백엔드 워크로드가 리소스에 대한 기기 액세스를 승인합니다.

다음 섹션에서는 MQTT 브로커를 사용할 때 인증 방법에 대한 권장사항을 제공합니다.

MQTT 브로커의 인증 방법 선택

IoT 백엔드에 따라 다양한 인증 방법이 지원됩니다. 일반적으로 사용되는 방법은 다음과 같습니다.

  • 사용자 이름 및 비밀번호 인증: 에지 기기에서 ID를 확인하기 위해 사용자 이름과 비밀번호를 제공합니다.
  • 토큰 기반 인증: 암호화된 보안 토큰을 사용하여 에지 기기의 ID를 확인합니다.
  • 맞춤설정된 인증 스키마: 커스텀 메커니즘을 구현하여 에지 기기의 ID를 확인합니다.

MQTT 브로커는 MQTT 표준의 일부로 사용자 이름 및 비밀번호 인증을 MQTT CONNECT 패킷의 기본값으로 지원합니다.

MQTT CONNECT 패킷에는 MQTT 브로커에 대해 클라이언트를 고유하게 식별하는 데 사용할 수 있는 Client Identifier 필드도 포함됩니다. 에지 기기는 연결을 설정할 때 MQTT CONNECT 패킷을 MQTT 브로커로 전송합니다.

MQTT 5.0은 MQTT CONNECT 패킷의 사용자 이름, 비밀번호, 클라이언트 식별자 필드 외에도 본인 확인 요청 응답 인증 흐름을 빌드할 수 있는 향상된 인증을 지원합니다. MQTT 5.0을 사용하면 에지 기기와 MQTT 브로커 간에 여러 AUTH 패킷을 교환할 수 있습니다.

사용자 이름 및 비밀번호 인증으로 비밀번호 저장소 사용

사용자 이름 및 비밀번호 인증의 경우 비밀번호 저장소를 사용하도록 MQTT 브로커를 구성합니다. 비밀번호 저장소는 MQTT 브로커에 연결되는 모든 에지 기기의 비밀번호를 관리할 수 있는 중앙 위치를 제공합니다. 기본적으로 사용자 이름, 비밀번호, 클라이언트 식별자 필드는 MQTT 사양에서 선택사항입니다. 따라서 사용자 이름, 비밀번호, 클라이언트 식별자 필드가 MQTT CONNECT 패킷에 있는지 확인하기 위해 인증 메커니즘을 설계합니다.

다음과 같이 비밀번호가 저장 시 및 전송 중에 암호화되었는지 확인합니다.

토큰 기반 인증 고려

토큰 기반 인증을 사용하면 에지 기기가 인증을 위해 MQTT 브로커에 토큰을 전송합니다. 기기는 토큰을 직접 생성하거나 다른 인증 서비스에서 토큰을 가져올 수 있습니다. 토큰은 비밀번호와 달리 단기간 지속됩니다. 토큰은 명시적 만료일이 있는 기간 동안만 유효합니다. 토큰을 검사할 때는 항상 만료일을 확인합니다.

JSON 웹 토큰(JWT)은 토큰 기반 인증을 구현하는 방법입니다. 에지 기기는 JWT를 생성하고 MQTT 브로커를 사용하여 인증할 수 있습니다. JWT는 MQTT CONNECT 패킷에 비밀번호 필드로 삽입됩니다.

JWT의 장점은 다음과 같습니다.

  • JWT는 토큰 서명에 사용되는 암호화 알고리즘을 선택할 수 있는 옵션을 제공합니다. JWT는 토큰 서명에 ECC와 같은 리소스 사용량이 적은 암호화 알고리즘을 사용할 수 있는 제한적인 에지 기기에서 잘 작동합니다.
  • 공개 키 암호화를 사용하면 비공개 키가 에지 기기에서만 사용되며 다른 당사자와 공유되지 않습니다. 비공개 키를 사용하면 사용자 인증 정보가 연결을 통해 전송되고 데이터 암호화가 필요한 사용자 이름 및 비밀번호 인증보다 안전하게 이 방법을 사용할 수 있습니다.

커스텀 인증 스키마 고려

일부 MQTT 브로커는 다양한 인증 메커니즘 및 프로토콜을 지원합니다. 예를 들어 MQTT 브로커가 맞춤설정된 인증 스키마를 지원하는 경우 다음을 지원하도록 구성할 수 있습니다.

  • 업계 표준 인증 프로토콜(예: OpenID Connect, 보안 보장 마크업 언어(SAML), LDAP, Kerberos, SASL(Simple Authentication and Security Layer)). 이러한 프로토콜은 기기 인증을 기존 ID 공급업체에 위임합니다. 일부 MQTT 브로커는 MQTT 브로커를 확장하여 새 프로토콜 및 ID 공급업체를 지원할 수 있는 향상된 인증 메커니즘과 확장 가능한 인증 메커니즘을 지원합니다.
  • 인증서 기반 상호 인증. 일부 MQTT 브로커는 mTLS 기반 인증과 같은 상호 인증 스키마를 지원합니다.

기기 액세스 제어 및 승인 권장사항

MQTT 프로토콜의 게시자 및 구독자 통신 패턴으로 인해 기기 액세스 제어는 MQTT 주제를 사용하여 정의됩니다. MQTT 주제는 기기가 IoT 백엔드와 통신하는 방법을 제어합니다. IoT 백엔드마다 액세스 제어 및 승인에 대한 구현이 다르므로, MQTT 주제 설정 방법에 대한 옵션은 IoT 백엔드 문서를 참조하세요.

단일 목적 서비스 계정을 사용하여 Google Cloud 리소스에 액세스

Google Cloud 리소스에 대한 액세스 권한은 리소스 액세스 허용 범위를 일련의 주 구성원과 바인딩하는 IAM 허용 정책에 의해 관리됩니다. 일반적인 주 구성원은 사용자 계정, 서비스 계정, 그룹입니다. 서비스 계정은 일반적으로 애플리케이션 또는 컴퓨팅 워크로드에서 클라우드 리소스에 대해 승인된 API 호출을 수행하는 데 사용됩니다. 서비스 계정을 사용하면 IoT 에지 기기에서 클라우드 리소스에 액세스할 수 있습니다.

기기 ID는 IoT 백엔드에서 관리하므로 에지 기기에서 Google Cloud 리소스에 액세스할 수 있도록 IoT 백엔드와 IAM 간에 ID를 매핑해야 합니다.

많은 기기를 관리하는 경우 각 Google Cloud 프로젝트의 서비스 계정 수에 대한 한도로 인해 기기와 서비스 계정 간에 직접 일대일로 매핑할 수 없습니다.

대신 단일 목적 서비스 계정 만들기에 설명된 대로 IoT 솔루션이 액세스해야 하는 클라우드 리소스에 연결된 서비스 계정을 만듭니다. 예를 들어 다음 각 사용 사례에 대해 고유한 서비스 계정을 만듭니다.

  • 소프트웨어 업데이트 패키지 다운로드
  • 대용량 미디어 파일 업로드
  • 지연 시간 스트림에서 데이터 수집

최소 권한을 구현하려면 각 서비스 계정에 사용 사례를 지원할 수 있는 충분한 액세스 권한만 있어야 합니다. 예를 들어 소프트웨어 패키지를 다운로드하는 데 사용되는 서비스 계정의 경우 Cloud Storage 버킷에 대한 읽기 액세스 권한만 부여합니다.

안전하게 기기에 액세스 토큰 배포

일반적으로 에지 기기는 MQTT를 사용하여 IoT 플랫폼과 통신합니다. 하지만 특정한 사용 사례의 경우 기기에 Google Cloud 리소스에 직접 액세스해야 할 수 있습니다. 예를 들어 다음 사항을 고려해 보세요.

  • 콘텐츠를 다운로드하려면 에지 기기는 다운로드 프로세스 중에만 Cloud Storage 버킷에 대한 읽기 전용 액세스 권한이 필요합니다.
  • Cloud Storage 버킷에 데이터를 업로드하려면 에지 기기는 버킷에 대한 쓰기 액세스 권한이 필요합니다.

이러한 사용 사례의 경우 액세스 토큰을 통해 Google Cloud 리소스에 대한 액세스 권한을 부여하는 워크로드 아이덴티티 제휴를 사용합니다. 워크로드 아이덴티티 제휴는 에지 기기에서 클라우드 관련 사용자 인증 정보를 프로비저닝할 필요가 없으며 수요에 따라 액세스 분산을 동적으로 수행합니다.

클라우드 리소스의 액세스 토큰을 기기에 배포하려면 기기 ID 공급업체와 Google Cloud 간에 워크로드 아이덴티티 제휴를 구성합니다. 워크로드 아이덴티티 제휴를 지원하려면 IoT 백엔드가 워크로드 아이덴티티 제휴 요구사항을 충족하고 사용 사례에 맞는 보안 권장사항을 따르는지 확인합니다.

워크로드 아이덴티티 제휴를 사용하여 Google Cloud 리소스에 액세스하려면 에지 기기에서 다음 단계가 포함된 OAuth 2.0 토큰 교환 워크플로를 구현해야 합니다.

  • 기기가 보안 토큰 서비스를 호출하고 자체 기기 사용자 인증 정보를 제공합니다.
  • 보안 토큰 서비스가 기기 ID 공급업체를 통해 에지 기기가 제공한 사용자 인증 정보를 검사하여 에지 기기의 ID를 확인합니다.
  • ID 확인이 성공하면 보안 토큰 서비스가 제휴 토큰을 에지 기기에 다시 반환합니다.
  • 에지 기기가 제휴 토큰을 사용하여 단일 목적 서비스 계정을 가장하고 단기 OAuth 2.0 액세스 토큰을 가져옵니다.
  • 기기가 단기 OAuth 2.0 액세스 토큰을 사용하여 Google Cloud API로 인증하고 필요한 클라우드 리소스에 액세스합니다.

단기 액세스 토큰의 액세스를 Cloud Storage의 특정 버킷과 객체로 제한하려면 사용자 인증 정보 액세스 경계를 사용합니다. 사용자 인증 정보 액세스 경계를 사용하면 단기 사용자 인증 정보에 대한 액세스를 제한할 수 있고 액세스 토큰이 손상된 경우 Cloud Storage 버킷에서 노출되는 리소스 수를 최소화할 수 있습니다.

워크로드 아이덴티티 제휴는 에지 기기에 대한 클라우드 액세스를 안전하게 배포하는 확장 가능한 방법입니다. 인증에 대한 자세한 내용은 Google에서 인증을 참조하세요.

클라우드 리소스에 대한 액세스 모니터링 및 감사

에지 기기가 인증된 API 요청을 통해 클라우드 리소스에 액세스할 때 로그 항목을 만들도록 Cloud 감사 로그를 사용 설정합니다. Cloud 감사 로그를 사용하면 Google Cloud에서 에지 기기가 수행하는 중요한 작업을 모니터링할 수 있습니다. 또한 Cloud 감사 로그는 문제를 조사하는 데 필요한 감사 trace와 로그를 만듭니다. 자세한 내용은 Google Cloud에 액세스하도록 서비스 계정 가장을 참조하세요.

다음 단계