インターネット上流リンクなしのLANでRaspberry Piを管理する

プライベートLAN上の二台のデバイスは、上流リンクがなくても保護された通信を交換できます。できないのは、選んだセキュリティモデルが前提とするサービスを魔法のように用意することです。したがって作業は半分が選択、半分が棚卸しであり、タスクに合う保護を選んだうえで、静かにインターネットへ手を伸ばすものをすべて洗い出すことになります。

この解説の前提は、両方のデバイスが同じプライベートネットワーク上で承認されたアドレスを持つことです。両方が同じWi-Fiに参加したという事実から到達可能性を推測しないでください——接続、ルーティング、アクセス規則が依然としてそれを決めます。

習慣ではなくタスクで保護を選ぶ

ターミナルセッションやサポート対象のファイル管理タスクにはSSHが適しており、そのアーキテクチャはサーバー認証、ユーザー認証、保護されたトランスポート内で運ばれるチャネルを分離しています。どの役割も商用VPNプロバイダーを必要とせず、インターネットへのデフォルトルートがないからといって機能を停止することもありません。

サーバーが許可すれば、追加のTCPサービスを一つだけ認可されたSSH転送で通せます——ローカルのリスナーは狭く束縛し、宛先は明示し、これは一つのサービスを転送するのであってEthernetセグメントを再現するのではないことを忘れないでください。

複数のアドレスやプロトコルへのルーティングされたアクセスは別の要件であり、ローカルで終端するVPNがそれを提供できます。その場合の相手は到達可能なローカルゲートウェイであり、インターネットのどこかにある端点ではなく、ゲートウェイには意図した経路、転送規則、サービス権限が依然として必要です。単一のアプリケーションがすでにTLSを正しく話すなら、それ自身に接続を守らせるのが最小の有効解であることがよくあります。

LANから出ていくものを棚卸しする

隔離されたベンチに依存する前に、ソフトウェア、ホストの識別情報、資格情報を整えておくか、組織がサポートするオフライン配布の手順を使ってください。ダウンロードコマンドは、取得元に到達できないマシンのインストール計画ではなく、障害の最中にそれを知るのは学ぶのに悪いタイミングです。

命名は意図的に行い、想定されたローカルDNSサービスか、文書化されたアドレス構成を使ってください。設定済みの公開リゾルバーは自分自身への経路を作りません。ソケットアドレスを変えることも、アプリケーションの識別確認を飛ばす理由にはなりません。答えが「ベンチは単にアドレスを使う」なら、それも書き留めてください——次のエンジニアが一度も設定されなかった検索ドメインに一時間を費やさないように。

次に、外部依存の認証と検証のモデルを読んでください——登録、IDプロバイダー、多要素承認、証明書状態の取得、時刻源です。どれも隔離ネットワークでは妨げになり得ます。保守ウィンドウの前に列挙し、その最中にはしないでください——間違った瞬間に見つけた依存は、五分の作業を丸一日に変えます。承認された到達可能な取り決めを用意するか、オフラインで動くモデルを選び、サービスがないからといって検査を黙って無効にしないでください。

識別確認はあるべき場所に置く

期待するホスト鍵や証明書は、信頼するプロビジョニング手順を通じて検証し、プロトコルが証明書の時刻を検証する場所では時計を正しく保ってください。スイッチを装置と共有しても、その装置が到達したい相手になるわけではなく、逆に考えるのは、同じセグメントにいる攻撃者があなたにさせたい過ちそのものです。

時刻は計画の中で独立した一行に値します。多くのプロトコルは、時計が十分にずれると、そうでなければ有効な資格情報を拒否し、ネットワーク時刻源のないPiは、何かが文句を言うまで何か月も静かにずれ続けられます。

上流リンクが実際にない状態で試験する

上流リンクを抜いてから、設計したとおりの保守作業を正確に行います——ターミナルセッション、ファイルのコピー、転送したサービス、ルーティングした接続です。拒否された識別や禁止されたリソースが依然として拒否されることを確認してください——うまくいく経路だけを示す設計は、まったく試験されていません。その間ログを読みましょう——興味深い障害は、結果を変えずに痕跡を残すものです。

ローカルの端点、保護の仕組み、その操作が使ったすべての依存を記録します。インターネットへの出口とローカル管理のための安全な経路は別の要件であり、それらを分けておくことが、前者を失ったときに後者を生き残らせます。