SORACOM × AWS IoT Core でSREする

SORACOM UG Hiroshima #12

1. SORACOM x AWS IoT CoreでSREする つながる車を「乗っ取らせない・異常に気付ける」ための仕組み SORACOM UG Hiroshima #12 butadora / KGモーターズ株式会社 1
2. 自己紹介 荒木 雅斗 / butadora SWE, SRE @KG Motors(東広島) 超小型モビリティロボット「mibot」 普段はリモート or 東京オフィス勤務 ex-サーバーエンジニア→SRE 出身は福岡 2
3. KGモーターズってどんな会社？ 東広島発 のモビリティスタートアップ(2022年設立) 超小型モビリティロボット mibot を開発 一人乗りの超小型EV、最高時速60km/h・航続距 離100km 原付ミニカー扱いで、普通免許で運転できる 2025年12月に初回納車、量産に向けて生産を拡大中 車体からソフトウェア・クラウドまで 自社で開発 3
4. mibot はソフトウェアで動く車(SDV: Software Defined Vehicle) スマホアプリ から施錠・状態確認・各種操作 車載ディスプレイ(Android SBC) がクラウドと常時接続 OTA でソフトウェアを無線アップデート その回線に SORACOM の IoT SIM を使っています → 「つながっていること」自体がプロダクトの価値。だから SRE が効く 4
5. 全体像 IaC: Terraform / Lambda デプロイ: lambroll + GitHub Actions 5
6. 今日お話しすること 1 2 3 4 5 困ること やること 知らない端末がクラウドにつながる 入口で止める — IMSI 検証 車から SIM を抜かれて悪用される SIM と車両をひも付ける — IMEI ロック 通信量の超過や不正な接続に気付かない 異常に気付く — Event Handler → Slack SORACOM の鍵が漏れる・権限が強すぎる 権限を分ける — SAM・Operator ― ハマりどころ — Metadata Service・API のクセ 1〜3 はどれも「人がコンソールを触らない(toil を減らす)」ように、出荷・接続の流れの中で自動で回しています 6
7. 1 入口で止める: プロビジョニング時の IMSI 検証 AWS IoT Fleet Provisioning の pre-provisioning hook を使う mibot(SBC) は Metadata Service から自分の IMSI を取得して申請 Lambda が SORACOM API で 自社の Operator にある SIM か を照合 状況 結果 自社の SIM の IMSI 許可 IMSI が無い / 他社の SIM 拒否 SORACOM API エラーなど 拒否 → fail closed: 判断できないときはつながせない 7
8. 2 SIM と車両をひも付ける: IMEI ロックの自動化 mibot(SBC) が起動時に Metadata Service で 自分の SIM に車両 ID をタグとして 書き込む Metadata Service: 端末から自分の SIM の情報を HTTP で読み書きできる 端末に認証情報を置かずに SIM と車両をひも付けられる IMEI が届いたら Lambda がタグで SIM を探し、IMEI ロック をかける 出荷ラインで人が SORACOM コンソールを触る作業をゼロに。失敗する前提で、待つ・やり直す・ダメなら通知 8
9. 3 異常に気付く: Event Handler → Slack 当初はメール通知のみ → Event Handler から Slack Webhook へ直接通知 通知するイベントは「止まる・危ない」に絞って 3種類・計5本 だけ 監視するもの ルール 通信量 月次データ通信量が 50% / 90% / 100% に達したとき 速度クラス SIM の速度クラスが変更されたとき IMEI ロック IMEI ロックで接続に失敗したとき(IMEI mismatched) AWS で中継(Lambda)する案もあったが 見送り 通知先の振り分けや整形が必要になったら、そのとき作る 今はシンプルな方が運用コストが低い 9
10. 4 権限を分ける: SAM・Operator SORACOM のアカウント・権限設計(SAM)は AWS IAM の考え方をそのまま踏襲 している AWS SORACOM KG での使い方 AWS アカウント Operator AWS と同じく dev / prd でアカウント分割 IAM ユーザー / ロール SAM ユーザー 用途ごと に分ける(IMSI 検証用 / IMEI ロック用) IAM ポリシー SAM 権限(JSON) API 単位で許可を絞れる SAM の AuthKey は Secrets Manager に保存し、Lambda は そのシークレットだけ 読める コスト: Operator・SAM ユーザーは自分で 無料で作れる、分けても SIM の料金は変わらない → 増えるのは Secrets Manager の $0.40 / シークレット / 月 くらい 10
11. 5 ハマりどころ 1 Metadata Service はセルラー経由でしか届かない Wi-Fi 接続中は失敗する → セルラー網にソケットを固定 2 カバレッジによる API エンドポイントの違い グローバル版( g.api.soracom.io )でも同じ認証情報・パスで叩けるが、Japan カバレッジの SIM は日本版( api.soracom.io )でないと返ってこない 3 dev / prd の行き来はスイッチユーザー 切り替え先ごとに信頼ポリシーが必要で、登録は ブラウザごと なので引き継げない(AWS SSO 的な仕組みがあると嬉しい) 11
12. まとめ SORACOM の API・Metadata Service・Event Handler は、SRE のパーツ としてそのまま使える 1 プロビジョニングでSIMの正当性を検証する 2 SIM と車両を自動でひも付けてオペミスをなくす 3 Event Handler を活用して異常を通知する 4 Operator・SAM ユーザーを用途ごとに分ける → SORACOM x AWS IoT Core の運用もSREしよう！ 12
13. 一緒に mibot をつくりませんか？ 東広島発の EV スタートアップで、車 × ソフトウェア × ク ラウド を丸ごと触れます 今日の話のような IoT / SRE の仕組みも、まだまだこれから リモート・東京・東広島、いろんな働き方のメンバーがい ます まずはカジュアルに面談しましょう！ 採用ページ: https://kg-m.jp/recruit (QR→) 13