インターネット接続を切ってください
(computer.rip)- CrowdStrike事故のような大規模なセキュリティ事件の後には「インターネットに接続すべきではなかった」という反応が出るが、多くの業務システムでは情報交換が中核機能であり、単純な遮断では解決しない
- 航空予約・スケジューリングシステムのように組織や地域の境界をまたぐシステムは、電話や電信を置き換えた通信インフラに近く、ネットワーキングを取り除くと本来の価値も失われる
- 「インターネットに接続されていない」は、単一機器、厳格なエアギャップ、データダイオード、プライベートWAN、VPNトンネル、限定的ルーティング、AWS private VPCまで含みうるため、脅威モデルが大きく異なる
- オフラインまたは制限接続環境では、OSアップデート、パッケージマネージャ、内部リポジトリ、TLS信頼ストア、クラウドライセンス、コンテンツ更新、Dockerイメージ処理まで、すべてが時間とコストを押し上げる
- より多くのシステムに制限的なネットワークポリシーを適用し、オフライン運用を考慮してソフトウェアを作ることはできるが、現在のソフトウェアエコシステムは依然としてインターネット接続をデフォルトとしている
「インターネットに接続するな」という言葉の限界
- 大規模なセキュリティ事故がニュースになるたびに、「こうしたシステムはインターネットに接続されているべきではない」という反応が繰り返される
- この判断はセキュリティと安定性の観点から直感的な魅力があるが、実際にそのように運用されている環境は多くない
- 核心的な問題は、「インターネットに接続しない」という言葉だけでは、実際の設計、運用コスト、脅威モデルを十分に特定できない点にある
現代の業務システムは通信装置に近い
- 抽象的にはコンピュータは計算によって価値を生み出せるが、産業現場のシステムは計算よりも情報技術としての性格が強い
- 情報技術は情報を入力し出力しなければならず、過去のようにオペレータがテープを挿入する方式は、リアルタイム通信より高コストで遅い
- 現代の業務用コンピュータの大半は通信装置として機能している
- 他の業務システムと接続されずに価値を生み出すシステムは多くない
- こうした接続は組織の境界や地理的な境界を越えることが多い
- 航空予約・スケジューリングシステムは電話や電信を置き換えたシステムから始まっており、ネットワークが機能そのものに含まれている
保守と運用にもネットワークが必要
- リアルタイム通信が業務目的に必須ではないシステムでも、ネットワーク接続は運用上大きな価値を持つ
- インターネット接続がなければ、ソフトウェア更新をどう取得するか、システムをどう監視するかの時点で行き詰まる
- システムが「完成」していて更新やリアルタイム監視が不要だと決めたとしても、ビジネス要件は時間とともに変化する
- ネットワーク接続はこうした変更に対応するコストを大きく下げる
「インターネット非接続」には複数のレベルがある
- 「インターネットに接続されていない」という状態は単一の意味ではなく、複数の実装形態の集合である
- あり得る形は完全分断から限定的接続まで広く分布している
- ネットワーク接続がまったくない単一機器
- プライベートLAN以外には接続がなく、セキュリティ境界をデータが越えない厳格なエアギャップ
- DVD-Rでデータをセキュリティ境界内に持ち込むエアギャップ
- cross-domain solution または data diode によって低セキュリティネットワークから高セキュリティネットワークへデータを移動する構成
- NSA認証のない cross-domain solution を使う構成
- プライベート広域網にも複数の段階がある
- 完全に独立した物理インフラと改ざん防止措置を備えたプライベートWAN
- 共有ダクト、leased dark fiber、lit fiber の wavelength を使う形態
- MPLSベースの virtual private ethernet
- 暗号化と認証を備えたトンネリングベースの virtual private ethernet
- 公衆通信網上のプライベートトラフィックも「非接続」と呼ばれる場合がある
- インターネットのような common-carrier network 上でハードウェア機器が暗号化・認証トンネルを構成する形態
- NSA認証のない機器を使う形態
- OSのネットワークスタックを低レベルで設定し、トンネル回避を防ぐ検証済みソフトウェアトンネル
- 検証水準の低いソフトウェアトンネル
- WireGuard と iptables スクリプトを組み合わせた形態
- 制限的なインターネット接続も同じ言葉でまとめられる
- ポリシーベースルーティングなどによってごく狭いトラフィックフローだけを許可するプライベートネットワーク
- 許可フローが古い Jira チケットに残っており、一部は「動かすために」追加された構成
- アウトバウンドは比較的緩く、インバウンドは厳格なファイアウォールベースの構成
- クラウド環境でも範囲は揺れる
- 外部ルーティングのないAWS private VPC
- PrivateLink などで他の private VPC と通信する VPC
- 接続された一部の VPC がインターネットとルーティングされる構成
- NAT Gateway と Internet Gateway はあるが、security group を双方向に厳格設定した構成
- これらの形態はすべて「インターネットに接続されていない」と呼ばれた事例があるが、攻撃面とリスクはそれぞれ異なる
- 航空予約システムに対して「インターネットに接続するな」と言うとき、完全な無ネットワーク状態を意味しないのであれば、実際には中間段階のどれかを指しており、各段階ごとに実務上の考慮事項が異なる
オフライン環境はコストとスケジュールを大きく増やす
- インターネット接続がない、または強く制限されたネットワークでソフトウェアを運用すると、スケジュールとコスト見積もりは大きく膨らむ
- AWS private VPC のような弱い形態でも、おおむね3〜5倍で見積もることができる
- 完全分断に近い強い形態では、10倍からさらに大きくなることもある
- ソフトウェアエコシステムのほぼ全体がインターネット接続を前提に設計されている
- OSはオンラインサーバから更新を取得しようとする
- 有償OSベンダーは、プライベートネットワーク内部の更新インフラを別料金ライセンスで提供することがある
- 無償OSは自力で対応できるが、最新技術を使うと大きな面倒が生じることがある
- 開発とデプロイの過程では、複数のパッケージマネージャと内部リポジトリの問題が繰り返し現れる
- パッケージマネージャごとにプライベート内部リポジトリ対応の水準が異なる
- 複数のパッケージマネージャ、呼び出し方法、実行環境が組み合わさり、複雑性が増す
- 内部サービスのTLS証明書も反復的な作業を生む
- プライベートネットワーク内部のサービスは、一般的なCAのルートプログラムに含まれる証明書を使えないことが多い
- JREのように別個の trust store を持つ構成要素があり、一部の技術スタックではライブラリによって動作が異なる
- OSの trust store があっても、各ツールが独自ストアを使うなら別途調整が必要になる
- クラウドライセンスと entitlement 確認も障害になる
- 一部のソフトウェアはクラウドライセンス確認のために外部接続を試みる
- 回避方法は大規模なファイアウォール例外追加からカスタムライセンス体系の発行まで幅広く、時間がかかることがある
- オフラインでのコンテンツ更新は、ベンダープロセスだけでも複雑になりうる
- あるエンタープライズソフトウェアの事例では、古いカスタマーサポートポータルと別個の entitlement ポータルを経由しなければならなかった
- アカウント開設とエスカレーションに3か月以上かかり、最終ポータルには無効なTLS証明書があった
- 文書化された更新適用手順がすでに動作せず、エンジニアとの長いメールのやり取りが必要だった
- 1年ライセンスに5桁金額を支払ったが、利用準備の過程でほぼ失効し、延長ライセンス発行の遅れによってCIパイプライン停止が発生した
- オフライン運用の難しさは、個々の作業のどれか1つが不可能だからではなく、すべての作業が少しずつ難しくなるdeath by a thousand cutsに近い
- オフライン環境を考慮していない製品は、その場しのぎのスクリプトや継ぎはぎ対応になりがちで、その技術的負債はオフライン環境を運用する顧客に押し付けられる
- Red Hat はこの領域に比較的よく対応しているが、節約できた時間の分だけコストを現金で支払うことになる
こうした環境はまれで、特定業界に集中している
- 強い形態の非インターネット接続環境は主に国防・情報機関で見られる
- 一部の銀行も強いネットワーク分離慣行を持っている
- 国防、情報機関、銀行はコストが高く時間のかかる業界としても知られており、こうした運用方式と無関係ではない
- 弱い形態の制限接続環境は主に金融や医療のような高規制産業に多い
- セキュリティを非常に重視してネットワークを強く閉じる一般的なソフトウェア企業も時折ある
今できる実用的な対応
- より少ないシステムがインターネットに接続される方向性そのものは悪い考えではない
- ただし現在のソフトウェア産業は、インターネットがない、あるいは制限された環境で快適に運用できるようには準備されていない
- 現実的な対応は、完全分断を叫ぶことよりも、制限的接続とオフライン対応性を高める方向に近い
-
ネットワークポリシーを可能な限り制限する
- 可能な限り多くのシステムに制限的なネットワークポリシーを適用すべきである
- クラウドプロバイダは以前よりこうした構成を作りやすくしている
- AWSでは実用的な非インターネットルーティング環境を運用するのは非常に簡単ではないが、不可能なほど難しくもない
- AWS managed service の範囲内にとどまれば、概して痛みは少ないが、コストは発生する
-
オフライン環境を考慮してソフトウェアを作る
- 外部に接続しなければならない機能は、可能であれば無効化できるべきである
- 無効化が難しいなら、利用する endpoint を顧客が変更できるべきである
- endpoint を変更できるようにするなら、顧客が独自 endpoint を運用できる方法も必要になる
- 単純な静的ファイルであれば、nginx とディレクトリ程度で簡単に提供できる
- APIであれば、内部実装を顧客に配布しなければならない可能性があり、保守負担が生じる
-
TLSと依存関係の前提を減らす
- オフライン環境では、他サービスへ接続するという小さな前提が複雑化する
- Let’s Encrypt に接続できることを前提にしてはならない
- オフライン環境はほぼ常に内部認証局を伴う
- system trust store を使うべきである
- デプロイ時点で要件や依存関係を取得してはならない
- Docker はパッケージを自己完結的にするという利点があったが、npm リポジトリなどに接続できないと起動できないコンテナもある
- Docker コンテナごとに TLS trust store を修正しなければならない場合があり、オフライン環境では Docker がかえって管理を難しくすることがある
CrowdStrike事故とインターネット接続の関係
- CrowdStrike事故について「なぜインターネットに接続されていたのか」という反応が何度も出たが、インターネット接続の有無は当時発生した問題とほぼ直交している
- CrowdStrike のコンテンツ更新は、理想的な環境であればオフライン環境にも迅速に提供されるべき種類の更新である
- 実際の強いオフライン環境では、内部の CrowdStrike 更新ミラーが数日、数週間、数か月、数年単位で遅れることがある
- その遅延が問題回避につながることはありうるが、それは2つの誤りが重なって偶然うまくいった状況に近い
1件のコメント
Hacker Newsの意見
セキュリティ／システム／運用の分野で働いていますが、この前提には根本的に同意できません。筆者が「そんなに簡単ではない」と言うのは理解できますし全面的に同意しますが、だからといってそれが仕事をうまくやっているという意味にはなりません
残念ながら、多くの場合はうまくやれておらず、業界全体が、うまくやれていなくても持ちこたえられる一方で、うまくやることは難しくなるように設計されています
デジタルサイネージを配備するなら、ネットワークアクセスは自分のサーバーのIPアドレスだけを許可リストに入れるべきで、署名済みアップデートと証明書ピンニング（certificate pinning）で確立された接続だけを受け付けるべきです
こうすれば、リモート攻撃者が手を出すのはほぼ不可能になります。モノのインターネット（IoT）の普及で大きくなったセキュリティ産業を見ると、開いたポートやデフォルトパスワードが残ったサイネージや、その他のIoT/SCADA/配備機器が確実に存在します
IoTは単なるコンピューターですが、すでに適切に運用できていないサーバーや仮想マシンよりも、さらに放置されがちなコンピューターでもあります
うまくやっているところもありますが、ごく少数です。うまくやることに報酬が与えられる構造ではないからです。「ベストプラクティス」やベンダーの指針に従うことは、うまくやっているという意味ではなく、ベンダーがサポートしてくれる程度にはやった、という意味であることが多く、多くの場合は制限のないネットワークアクセスを意味します
ネットワークのバグ、暗号の脆弱性、設定ミス、その他リモート攻撃者がシステムを悪用できる問題を、なお心配する必要があります。この主張をするなら、単により厳しくロックダウンした例ではなく、文字どおりインターネットに接続されていない例を挙げるべきです
ブログ筆者とどこで意見が分かれているのかよく分かりません。あるいは、人々にその能力がないため、インターネット接続システムのセキュリティを改善することは根本的に不可能だ、という意味なのでしょうか？
スウェーデンにはインターネットから分離されたプライベートネットワークSjunetがあり、医療提供者が利用しています。目的は、コンピューターを価値ある通信機器にしつつ、病院のITをインターネット全体にさらさないことです
Sjunetのメンバーは、自分たちのネットワークを把握し、ITを厳格に統制していることが期待されています
Sjunetは業界単位のエアギャップ環境と見ることもできます。セキュリティを改善しつつ、各組織が巨大な許可リストを持つ独自のエアギャップネットワークを運用するよりは、コストが小さいと考えられます
偽りの安心感を与え、悪いセキュリティポリシーの言い訳にもなります。帯域幅は低く、高価です
郡役所や市役所のような機関を接続し、市民の個人情報が保存された中央データベースにアクセスできるようにするネットワークです。住所変更、新しい身分証の発行、出生・婚姻登録などを行う際に使われます
私の知る限り、「Źródło」アプリは別の「エアギャップ」コンピューター上で実行され、インターネットには接続できませんが内部ネットワークにはアクセスでき、スマートカードによる暗号学的クライアント証明書で認証します
すべて最新のパッチが適用されていますか？人々が適当なUSB機器を挿さないと分かっているのでしょうか？
Torに似ているけれど、怪しいものはない感じだといいですね
制御エンジニアとして何百台もの機械を作ってきた。フィールドバスネットワーク用のイーサネットケーブルはあるが、絶対にインターネットに接続されてはいけない
近所の工業団地にある工具・金型工場のどこにも、インターネットにさらしてはいけないイーサネットポート付きのCNC機械がある。カスタム設備、コンベアライン、プレス、ロボット、CNC、ポンプステーションなどがあるあらゆる製造工場はイーサネットを使っているが、インターネット公開には適さないPLCとHMIシステムを使っている
記事は、現代の業務用コンピュータはほぼ主に通信装置であり、他の業務システムとつながらずに価値を生む実務システムは多くないと言っているが、製造業全体と、その製造業が作る電子機器を無視している
何百万もの組み込みシステムとPLCは、1ミリ秒ごとに物理・論理デジタル入力の状態が変わったかどうかを確認し、変わっていれば物理・論理デジタル出力の状態を変えながら、一日中価値を生み出している
鋳物が100年以上前に作られ、最後のアップデートが2003年にレシピ設定用PLCと白黒画面を取り付けたことだった抵抗溶接機に、2024年式のセキュリティシステムを入れる必要はない。クリップボードを持って行って目標値を入力し、正確に鋼を溶かせばよい
通常こうした機械に接続するには、ノートPCとイーサネットのパッチケーブルを持って機械の前まで歩いていく必要がある。それ以上が必要なら、顧客にはファイアウォールのある運用技術（OT）ネットワークに置くか、TosiboxやIxonのようなSCADA/VPN機器で情報技術（IT）とOTの間をつなぐことを期待する
あなたが扱っているものは、誰かが悪用したがる対象ではないかもしれないが、PLCは重要インフラや高度な製造施設でよく見つかるため、悪意ある行為者にとって魅力的な標的だ。重要インフラを悪用しようとしたり、いつかエンジニアリング用ノートPCのような高価値エンドポイントが直接接続する可能性のある、セキュリティの甘い装置を感染させようとしたりするかもしれない
https://www.cisa.gov/news-events/cybersecurity-advisories/aa... - Water Infra
https://claroty.com/team82/research/evil-plc-attack-using-a-...
インターネット中心の開発慣行が使えなくなるからシステムをエアギャップすべきではない、という主張にはやはり納得できない。この主張はばかげていると思う
イーサネットポートをエポキシで塞ぐべきシステムなら、そもそもインターネット中心の開発慣行でプログラミングすべきではなかった。MRI装置が起動時にNPMからJS依存関係を取得するって？ 即刑務所行きだ。比喩ではなく本当に
McDonald’sのキオスクをいじる人の動画を見て以来、いろいろな場所で見かける機器で同じことを試し始めた
あるフードコートには、Windowsが入っていてインターネットに完全アクセス可能なキオスクがあった。誰かがマルウェアをダウンロードしてクレジットカードデータを盗めたはずだ。使うたびに電源を切るか画面にメッセージを残していたら、最終的にキオスクモードで動かし始めた
もう一つは駐車場のキオスクだったが、まったく強化されていなかった。犯罪者たちはまだ気づいていないようだ
三つ目はビールブランドのインタラクティブディスプレイだった。大きな被害を生むものではなかったが、メモ帳を開いて「Drink water」と残しておくのはよかった。最終的に電源を切られ、それも解決策ではある
「通りすがりの人にお金を渡さないこと」は要件リストのかなり上位にあるべきだろうが、現実はそうではなかった
この部分は本当に共感できる。IntelliJのJRE信頼ストアがzscaler用の新しい証明書を使う必要があることを理解させようとしたのだが、選択可能なJDKが二つか三つあり、それぞれの信頼ストアに新しい証明書を入れたのに、なお動かず理由が分からなかった
hamnetもある。44NetのIPブロック上で、一部はインターネットルーティング可能で、一部はそうではない
https://hamnetdb.net/map.cgi
アマチュア無線の周波数帯を使うため、興味深い制約がある。商用利用は完全に禁止されている
それがその周波数帯の社会的契約なので、136kHzから241GHzまで多くの帯域に安価にアクセスできるが、お金を稼ぐことはできない
オランダとドイツでだけかなり広く普及している: https://hamnetdb.net/map.cgi 。ここスペインでは、私の近くのどこでも使えない
航空会社の予約システムが少なくともネットワークには接続されるべきだというのはかなり明らかに思えるし、全部オフラインであるべきだと主張する人はあまり見たことがない。しかし例えば、作業場の旋盤が今回の件で止まったという話も聞いた
本当にオンラインである必要があったのかは考えるべきだ。もちろん理由はあるだろうが、その理由はリスクと比べて評価しなければならない
ほかにも冷蔵庫、やかん、ガレージドアのように、インターネットにつながったもっとばかげた例がたくさんある。これらがCrowdStrikeの事故の影響を受けたかどうかは分からないが、受けていなかったとしても次は時間の問題にすぎない
接続されていないシステムは「非常に、非常にうっとうしい」という主張については、ユーザーとしての経験上、すべてのセキュリティは「非常に、非常にうっとうしい」。二要素認証、強制的なパスワード変更、ロックされたデバイス、マルウェアスキャナー、リンクのサニタイズまで、一部は必要で一部はでたらめだろうが、どれがどれかを見分ける資格はなく、全部が摩擦を生むことは確かだ
私が得た大きな結論は、「これらすべてのシステムをインターネットに接続すべきではない」ということではなく、別のいくつかの点だった。
第一に、こうしたシステムではアウトバウンドのネットワークフローを許可してはならない。そうすれば自動更新はすべて止まり、その後は内部の配布チャネルで管理できる。
第二に、そうしなくても多くのエンタープライズ向けソフトウェア製品では自動更新をオフにできる。Windowsが代表例で、CrowdStrike自体も同様だ。CSの顧客の中には、自動更新をオフにして手動配布にすることで被害を避けたところがあったと聞いている。
第三に、2番に加えて、多少のスモークテストを通した更新を段階的に配布すべきだ。念のために。やはりCSの顧客の中には、段階的配布により一部の機器だけが影響を受けるように抑えたところがあったと聞いている。
軍の顧客に最先端のAIソリューションを納品していた時期のことを、かなりうまく要約した文章だ。労力の80%は、インターネットを前提としたツール群をエアギャップ環境でスムーズに動くようにすることに費やされていた。