自宅MQTTサーバーをDockerで構築｜ACLでなりすましを遮断【自宅センサー基盤 #3】

はじめに

第1回で基板を作り、第2回でその基板から Wi-Fi 経由でデータを飛ばしました。では、飛ばした先には何があるのか。 それが今回の話です。

センサーの値を 60 秒ごとに投げつけても、受け止める相手がいなければ何も残りません。今回作るのは、受け止める人（MQTT ブローカー）・仕分ける人（Telegraf）・貯める人（InfluxDB） の3人組です。全部 Docker Compose で1つのディレクトリにまとめました。

そして、この3人組の安全を決めているのが、MQTT の ACL に出てくる %u という2文字です。たった2文字で「1台の鍵が漏れても、他の機体になりすませない」という性質が手に入ります。実際に自分でなりすましを試して、遮断されることを確かめたところまで書きます。

📝 この記事でやること

• MQTT・時系列データベース・Telegraf が何者なのかを、使う前に整理する
• Docker Compose で3サービスを立てる。ポートをどのアドレスにバインドするかの設計判断
• UFW は Docker の公開ポートに効かない。 ではどう守るのか
• ACL の %u 置換でなりすましを構造的に潰す。自分で6パターン試した結果つき
• ACL 違反の publish は、エラーにならず黙って捨てられる。 この罠の見つけ方
• パスワードを画面にも ps にも出さずに発行するスクリプト
• InfluxDB のトークンを3本まとめて露出させた事故と、その後始末

🧭 前提：MQTT・時系列DB・Telegraf とは

サーバーの中身に入る前に、登場人物3人の役割をはっきりさせておきます。すでにご存じの方は次の章へ飛んでください。

MQTT — 郵便受けに投げ込む通信

MQTT（MQ Telemetry Transport）は、IoT でよく使われる軽量なメッセージングプロトコルです。HTTP と決定的に違うのは、送る側と受け取る側が互いを知らないことです。

センサー基板は「サーバーの /api/telemetry に POST する」のではなく、home/sensor/sensor_001/telemetry という名前の郵便受けに投げ込むだけ。その郵便受けを見張っている人が誰なのか、何人いるのか、基板は知りません。この仲介役がブローカー（今回は Mosquitto）です。

第2回で書いたファームウェアが使うトピックは、2本だけです。

なぜ HTTP POST ではなく MQTT なのか。 以前 ESP32 から HTTP で JSON を POST する記事も書きましたが、あの方式は1回ごとに接続を張り直します。60 秒ごとに一生投げ続ける用途では、接続を張りっぱなしにできる MQTT のほうが素直です。受け手が増えたときに送信側を触らなくていい、という点も効きます。

時系列データベース — なぜ RDB ではないのか

センサーのデータは「時刻と、そのときの値」の繰り返しです。1台が 60 秒ごとに 15 項目を送ると、1日で約 2 万点。台数を増やせばそのまま倍々に増えます。

これを普通のリレーショナルデータベースに入れても動きはしますが、時系列データベースはこの形だけに特化して作られています。

Telegraf — ブローカーと DB の間を埋める

MQTT ブローカーはメッセージを配るだけで、保存はしません（retain の最後の1通を除く）。InfluxDB は受け取ったものを保存するだけで、自分で取りに行きません。この2つの間には、誰かが立つ必要があります。

Telegraf は、InfluxDB の開発元が公式に出しているデータ収集エージェントです。「どこから読むか」（input プラグイン）と「どこへ書くか」（output プラグイン）を設定ファイルで指定するだけで、その間を延々と運んでくれます。今回は input に mqtt_consumer、output に influxdb_v2 を指定しています。

ここを自作せずに既製品を使った理由は、後半の「なぜ Telegraf なのか」で比較表つきで書きます。

🏗️ 構成：Docker Compose 3本

前提が揃ったので、実際の構成です。サーバーは Ubuntu 26.04 LTS の自宅マシン1台（26.04 へのアップグレード記録はこちら）。ここに Docker Compose で3サービスを追加しました。

ディレクトリはこの形です。最初から compose 管理にしました。既存のサーバーに「compose の外で動いているコンテナ」を増やすと、後から全体像が追えなくなるからです。

~/neuralhub-smarthome/
  ├ docker-compose.yml
  ├ .env                     ← 600・シークレット・.gitignore 対象
  ├ .gitignore
  ├ mosquitto/
  │   ├ mosquitto.conf       ← 600
  │   ├ acl                  ← 600
  │   └ passwd               ← 600・PBKDF2-SHA512 ハッシュのみ
  ├ telegraf/telegraf.conf
  ├ grafana/                 ← ダッシュボード JSON のバックアップ
  ├ add-sensor.sh            ← 基板追加の自動化
  └ devices.yaml             ← device_id → 名前/場所/用途 の台帳

なお 192.168.0.9 は自宅 LAN 内のプライベートアドレスで、外部から到達することはできません。以降に出てくる IP もすべて同様です。

ポートをどのアドレスにバインドするか

Docker の ports: は、書き方によってどこから見えるかが変わります。ここは意識して分けました。

ports: - "1883:1883" と書くと 0.0.0.0、つまり全インタフェースで待ち受けます。アドレスを明示して書くだけで、露出範囲を1行で絞れます。

💾 データの置き場所：bolt は SSD、engine は HDD

「全部 Docker のボリュームでいいや」で済ませなかった部分です。サーバーには SSD と HDD の両方があるので、性質で分けました。

InfluxDB 2 系のデータは、性格の違う2つに分かれています。bolt はメタ情報を持つ小さなキーバリューDBで、細かいランダムアクセスが走ります。engine は TSM ファイル（実際の時系列データ）で、こちらは順に書き足されて容量が増えていきます。

小さくてランダムに触られるものを SSD に、大きくて順に増えるものを HDD に。 記憶装置の得意分野に合わせただけですが、これをやっておくと「容量が増えたから SSD を買い足す」という話にならずに済みます。

データ量の見積もりは、1台 30 秒間隔・約 15 フィールドで1日あたり約 4.3 万点。5台に増やしても圧縮後で年 300MB 程度の計算でした。実際の運用は 60 秒間隔なのでこの半分です。HDD の空きが 2.6TB あることを考えると、容量はまったく問題になりません。

uid 1000 の落とし穴

HDD 側のディレクトリ /data/storage4 は drwx------（所有者のみアクセス可・uid 1000）でした。このままコンテナを既定のユーザーで起動すると、bind mount 先のディレクトリを辿れずに失敗します。

対処は、compose の全サービスを user: "1000:1000" で起動することです。1883 も 8086 も 1024 以上のポートなので、root 権限は要りません。

これには副次的な効果もありました。600 で置いたシークレットファイルを、コンテナの実行ユーザーが読めないという問題も同時に消えます（同じサーバーの Grafana は uid 472 で動いていて、実際にこれを踏んでいます）。

シークレットを env_file に書かない

ここは設計として意図的に選んだ部分です。compose の env_file: と environment: は使っていません。

代わりに、.env（パーミッション 600）を読み取り専用でマウントして、起動コマンドの中で source する方式に統一しました。

    volumes:
      - ./.env:/run/secrets/influxdb.env:ro
    entrypoint: ["/bin/sh", "-c"]
    command:
      - "set -a; . /run/secrets/influxdb.env; set +a; exec /entrypoint.sh influxd"

set -a は「以降に定義した変数を自動で export する」という指定です。ファイルを読み込んで環境変数に展開し、set +a で元に戻してから本来のエントリポイントを exec します。プロセスの環境変数としては存在するが、コンテナの設定情報には残らないという状態になります。

効果は数えて確認しました。3コンテナぶんの docker inspect 全文を検索して、シークレット由来の文字列7種はいずれも0件。

🔐 ACL の %u 置換で、なりすましを塞ぐ

MQTT ブローカーは、素で立てると誰でも接続できて、誰でもどのトピックにも書けます。 家庭内 LAN であっても、その状態で 24 時間動かし続けるのは気持ちが悪い。

mosquitto.conf の要点はこれだけです。

allow_anonymous false
password_file /mosquitto/config/passwd
acl_file /mosquitto/config/acl

persistence true
persistence_location /mosquitto/data/
autosave_interval 300

max_keepalive 120
max_packet_size 8192
message_size_limit 8192

1行目の allow_anonymous false で匿名接続を禁止し、passwd（PBKDF2-SHA512 のハッシュのみが入る）で認証、acl でトピックごとの権限を決めます。

1デバイス＝1アカウントにする

パスワードは全機体で共通にしない、というのが出発点です。センサー基板は部屋に置きっぱなしで、しかもフラッシュの中に認証情報が入っています。1枚が誰かの手に渡ったとき、そこから全体が抜けないようにしておきたい。

そこで MQTT のユーザー名を device_id そのものにしました。sensor_001 という基板は、sensor_001 というユーザーでログインします。

ACL 全文

そのうえで、ACL はこれだけです。機体を増やしても、このファイルは1行も増えません。

# 既定は「拒否」。ここに書かれた組み合わせだけ許可される。
# pattern 行は全ユーザーに適用され、%u はログイン中のユーザー名に置換される。

# --- センサ基板 (ユーザー名 = sensor_00X) ---
pattern write home/sensor/%u/telemetry
pattern write home/sensor/%u/state
pattern read  home/sensor/%u/cmd/#

# --- IR 基板 (ユーザー名 = ir_00X) ---
pattern write home/ir/%u/state
pattern read  home/ir/%u/send
pattern read  home/ir/%u/learn

# --- 取り込み専用 (InfluxDB へのブリッジ) : 読み取りのみ ---
user telegraf
topic read home/#

# --- 保守・疎通確認用 ---
user ops
topic readwrite home/#

pattern 行の %u が、接続してきたユーザー名に置き換わります。 これが設計の核心です。

ユーザー名と、書き込めるトピックの階層が、ブローカーの中で自動的に紐づきます。 結果として次のようになります。

実際に試した6パターン

設定を書いただけでは「たぶん効いているはず」で終わってしまうので、自分でなりすましを試しました。

T4b と T6 が、双方向で試したなりすましです。既存の機体が新しい機体を騙ることも、新しい機体が既存を騙ることも、どちらもできません。

罠：ACL 違反はエラーにならない

ここで1つ、知らないと確実にハマるポイントがあります。

では、どうやって遮断を確認するのか。別のトピックの retain を見ます。

state トピックは retain=true で運用しているので、ブローカーには常に「最後に書かれた1通」が残っています。 そこで、

1. sensor_002 の state に online が retain されている状態を作る
2. sensor_001 として接続し、home/sensor/sensor_002/state へ別の値を publish する
3. retain された値を購読して読み出す

3 で読み出した値が online のまま変わっていなければ、2 の publish は届いていない、つまり ACL で遮断されたと確定できます。送信側の戻り値ではなく、受信側の状態で判定する。 これが上の表の T4b・T5・T6 で使った方法です。

🔑 パスワードを画面にも ps にも出さずに発行する

基板を1枚増やすたびに、MQTT のアカウントを1つ作ります。これを手作業でやると、パスワードがどこかに残ります。

• コマンドライン引数に書けば、ps で他のユーザーに見え、シェルの履歴にも残る
• 画面に表示すれば、ターミナルのスクロールバックに残り、スクリーンショットにも写る

そこで発行を add-sensor.sh に閉じ込めました。要点はこれだけです。

umask 077
PW="$(openssl rand -hex 20)"
printf '%s:%s\n' "$DEV" "$PW" > .pwtmp
chmod 600 .pwtmp
docker run --rm --user 1000:1000 -v "$PWD:/w" eclipse-mosquitto:2 mosquitto_passwd -U /w/.pwtmp
cat .pwtmp >> mosquitto/passwd
: > .pwtmp
docker compose kill -s HUP mosquitto

1行ずつ見ると、それぞれに理由があります。

最後の HUP も地味に効きます。基板を1枚追加するのに、他の基板の接続を切る必要がない。 コンテナを再起動すると、動いている全機体が一度切断されてしまいます。

🔀 なぜ Telegraf なのか

MQTT から読んで InfluxDB に書くだけなら、Python で 150 行も書けば動きます。実際その案も検討しました。

決め手は真ん中の2行です。再接続・バッファ・バッチ書き込みは、自分で書くと必ず作り込みになります。「MQTT から読んで DB に書く」だけなら 30 分で書けますが、そのあとに来るのは以下の質問です。

• ブローカーが再起動したら、勝手に再接続するか
• InfluxDB が落ちている間に届いたデータは、どこへ行くのか
• 1点ずつ書いていないか（毎秒 HTTP リクエストを投げていないか）
• センサーが1つ壊れてフィールドが欠けた JSON が来たとき、例外で止まらないか

これらは全部、公式の収集エージェントなら設定1行で済んでいる部分です。Node-RED も候補でしたが、データ取り込みの常時経路に GUI ツールを置かないという判断で外しました（自動化の用途では今も便利です）。

telegraf.conf の中身

[agent]
  interval = "10s"
  flush_interval = "10s"
  metric_buffer_limit = 100000   # InfluxDB 停止中もメモリ上に退避し、復旧後に流す
  omit_hostname = true

[[inputs.mqtt_consumer]]          # (1) telemetry -> measurement "env"
  servers = ["tcp://mosquitto:1883"]
  topics = ["home/sensor/+/telemetry"]
  qos = 1
  client_id = "telegraf_ingest"
  persistent_session = true
  data_format = "json"            # v1 パーサ
  name_override = "env"
  tag_keys = ["device_id"]

[[inputs.mqtt_consumer]]          # (2) state -> measurement "device_state"
  topics = ["home/sensor/+/state", "home/ir/+/state"]
  client_id = "telegraf_state"    # (1)と別IDにする（同一だとブローカーに切断される）
  name_override = "device_state"
  tag_keys = ["device_id"]
  json_string_fields = ["status", "fw", "ip", "sensors_*"]

[[outputs.influxdb_v2]]
  urls = ["http://influxdb:8086"]
  organization = "neuralhub"
  bucket = "home_sensors"

mqtt_consumer を2つ書いているのがポイントです。

measurement を2つに分ける理由

分けているのは、型の衝突を構造的に避けるためです。 InfluxDB のフィールドには型があり、同じ measurement の同じフィールド名に数値と文字列を混ぜて書くと拒否されます。 測定値と状態文字列を1か所に流し込むと、いずれ必ずここで詰まります。

入り口の時点で別の measurement に分けておけば、そもそも混ざりません。 第1回で「温湿度が2系統ダブっているのは、判断を受信側に倒すため」と書きましたが、これも同じ発想です。後で困る組み合わせは、最初から作らない。

state 側の json_string_fields に sensors_* とワイルドカードを書いているのも同じ理由で、新しいセンサーが増えても設定を触らずに済みます（ネストした sensors{} は sensors_bme280 の形に平坦化されて届きます）。

state は retain=true なので、Telegraf が再接続した直後に最新の state が再送されて DB に入ります。 LWT（{"status":"offline"}）も同じ経路を通るので、機体が落ちた記録も自動で残ります。

🗄️ InfluxDB：トークンをスコープで縛る

InfluxDB 側は素直です。組織とバケットを1つずつ作って終わりです。

最後の行は第2回で決めた設計です。基板は timestamp を送りません。 NTP が同期する前に送信してしまったとき、壊れた時刻のデータが DB に入るという事故を、構造的に防ぐためです。60 秒間隔の環境データなら、受信時刻との差は誤差の範囲に収まります。

届いたデータを Data Explorer で見る

なお、この画面は LAN の別の PC から http://192.168.0.9:8086 を叩いても出てきません。ssh -L 8086:127.0.0.1:8086 <サーバー> でトンネルを掘り、手元の localhost:8086 として開いて撮ったものです。8086 が LAN 側から見えないこと自体が、バインド先を 127.0.0.1 に絞った効果というわけです。

トークンは用途ごとに分ける

InfluxDB 2 系のアクセスはトークンで制御します。ここで admin トークンを使い回さないのが要点です。

Telegraf は書くだけ、Grafana は読むだけ。それ以外は何もできません。 仮に Grafana の設定からトークンが漏れても、できるのは1つのバケットを読むことだけです。

💥 やらかし：一覧コマンドがトークン3本を吐いた

発行済みトークンの権限を確認しようとして、トークンの値そのものを作業ログに残しました。

再起動して壊れないかを確かめる

自宅サーバーは停電もするし、こちらの都合で再起動もします。電源が落ちてデータが消える構成だと意味がないので、確認しました。

既存環境への影響も見ています。サーバー上のコンテナは 17本から20本に増えましたが、もともと動いていたサービス（:3000 / :4000 / :5002 / :6379 / :8888 / :3001 / :9090）はすべて生存していました。既存の compose に手を入れず、新しいプロジェクトとして足したので、当然といえば当然の結果です。

🧾 名前を DB に入れない — devices.yaml

最後に、地味ですが後から効く設計を1つ。

基板には sensor_001 のような ID しかありません。「リビング」「寝室」といった人間が読む名前は、どこにも入っていないのです。

これは面倒に見えますが、意図的です。名前を InfluxDB の tag に入れると、名前を変えた瞬間に過去データの系列が分裂します。

模様替えで基板を隣の部屋に移した、名前の表記を変えた。それだけでグラフが途中で切れるのは、明らかに間違っています。 時系列データが持つべきなのは「どの機体か」であって、「その機体が今どう呼ばれているか」ではありません。

そこで台帳は別ファイルに置き、表示層で名前を当てる構成にしました。

devices:
  sensor_001:
    name: "未設定"
    location: "未設定"
    purpose: "環境モニタ"
    hardware: "ESP32-S3 / BME280 + BH1750 + SEN63C"

基板を増やすときにやるのは、devices.yaml に数行足して、生成スクリプトの出力を Grafana の変数に貼るだけ。 パネルの編集は不要です。名前を変えたくなったら、この YAML を書き換えれば表示だけが変わり、過去のデータは1本の系列のまま残ります。

✅ まとめ

これで、基板が投げたデータがサーバーに 365 日ぶん貯まるところまで通りました。ただし今は、データベースの中を覗かないと何も見えません。

次回は最終回、Grafana でダッシュボードを作ります。温湿度の2系統を1枚のグラフに重ね、CO2 が 1000ppm を超えたら赤くし、基板を増やしたらパネルが自動で増えるところまで作り込みます。1枚の基板が、ようやく部屋のグラフになります。

関連記事

• KiCadで作るESP32-S3センサー基板｜設計から手はんだ実装まで【自宅センサー基盤 #1】 — 今回データを送ってくる基板を作った回
• ESP-IDFで自作するI2Cセンサードライバ｜vTaskDelayの罠【自宅センサー基盤 #2】 — 今回サーバーが受け取るデータを作っている回
• Grafanaで作る自宅環境ダッシュボード｜8パネルの設計【自宅センサー基盤 #4】 — 今回貯めたデータを1画面にする回
• Ubuntu 26.04 LTS アップグレード手順｜24.04からの移行を実機記録で解説 — このサーバーの OS
• ESP32-S3 × ESP-IDF｜cJSONとHTTP ClientでJSONをPOST送信 — MQTT ではなく HTTP を選んだ場合の実装
• ESP32でgRPC vs JSON 実測比較｜シリアライズ2.7倍速・データ量1/3 — 通信プロトコルを実測で比べた回