会社の Web サイトを動かすサーバーには、が入っています。多く使われているのは、Ubuntu や Red Hat Enterprise Linux のような汎用の Linux です。汎用の OS は、ファイルの共有、遠隔からの操作、プログラムの開発など、どんな用途にも使えるように多くの機能を最初から備えています。ところが Web サイトを配信するだけなら、その多くは一度も使いません。
使わない機能でも、動いている限り外から狙われる入口になります。この記事では、Web サーバーの OS から何を削れば攻撃される入口を減らせるのか、自分たちで専用の OS を作るべきかを順に見ていきます。シリーズ「オープンソースと AI 時代のセキュリティ」の4本目で、シリーズ全体の入口はオープンソースの時代は終わるのかです。
Web サーバーの OS から削るのは、コマンドを打ち込む画面（シェル）、遠隔からログインする仕組み（SSH）、ソフトを追加する道具、Web の配信に使っていないサービスが中心です。削った OS を自分で作る前に、不要な機能をあらかじめ省いた形で配られている専用の OS を選んでください。Talos Linux、Bottlerocket、Flatcar Container Linux がその例です。AI の手を借りれば OS を自作することもできますが、見つかる弱点を直し続ける仕事を自社がずっと引き受けることになります。オープンソースの OS を改造して削る場合は、社外に配るかどうかでライセンスの義務が変わり、元の製品名は名乗れません。
この記事の調べ方
削るべき機能の考え方は、米国国立標準技術研究所（NIST）のサーバーの安全対策の手引き（SP 800-123）を根拠にしました。各 OS とコンテナイメージの特徴は、それぞれの公式サイトと公式の説明文書から取っています。ライセンスの義務は GNU GPL・GNU AGPL・Apache License 2.0 の条文とフリーソフトウェア財団の質疑集を、商標の扱いは Canonical 社と Red Hat 社の公式の方針を読みました。はてなベースでは、この記事で挙げた OS をまだ試していません。ライセンスの説明は条文の一般的な読み方で、個別の判断は弁護士などの専門家にご確認ください。
使わない機能も、攻撃される入口になる
攻撃される入口の広さを、セキュリティの分野ではと呼びます。サーバーで動くサービスや、外からの通信を受け付ける口が1つ増えるたびに、この領域は広がります。入っているプログラムのどれか1つに弱点が見つかれば、そこから侵入される可能性があるからです。
NIST は、サーバーの安全対策の手引き SP 800-123 で、この考え方をはっきり書いています。サーバーはできれば1つの用途だけに使い、要らないサービス・アプリケーション・通信の方式は取り除き、取り除けないものは止めるように求めています。理由は、サービスを1つ足すたびに、攻撃者が入り込む道が1つ増えるからです。手引きはこれを「少ないほど安全」と言い表しています。
同じ手引きは、止めるより取り除くほうがよいとも書いています。止めただけのサービスは、攻撃者に設定を書き換えられれば再び動き出しますし、担当者の操作ミスで動き出すこともあります。取り除いてしまえば、設定を書き換える攻撃は成り立ちません。サービスが減れば記録（ログ）の量も減り、普段と違う動きを見つけやすくなる、という利点も挙げています。
守る対象を減らせば、点検や更新の手間も減ります。使っていない機能の弱点も、見つかれば更新しなければなりません。初めから入っていなければ、その更新も要りません。汎用の OS と、機能を削った専用の OS とで、外からの入口と侵入後に使われる道具を比べると、次の図のようになります。
Web サーバーの OS から削る機能
上の図の左側に並べたのは、汎用の OS に入っていることが多い機能です。NIST の手引きは、必要でなければ取り除くものとして、ファイルとプリンターの共有、無線のネットワーク、遠隔操作の仕組み、ディレクトリサービス（利用者やパソコンの情報をまとめて管理する仕組み）、メールの送受信、と開発の道具、システムとネットワークの管理の道具を挙げています。Web サーバーとして使うなら、要るのは Web の配信だけで、ほかはほとんど使いません。
中でも、侵入されたあとの被害を大きくするのが次の表の機能です。表では、それぞれの機能が普段何に使われ、残しておくと何が起きうるかを並べました。
| 削る機能 | 普段の使い道 | 残しておくと起きうること |
|---|---|---|
| シェル（コマンドを打ち込む画面） | 管理者がサーバーを操作する | 侵入した人が、サーバーの上で好きな命令を実行できる |
| SSH（遠隔からのログイン） | 別の場所からサーバーに入る | パスワードや鍵が漏れると、そのまま入られる |
| パッケージマネージャー（ソフトを追加する道具） | ソフトの追加と更新 | 侵入した人が、攻撃用の道具を取り込める |
| コンパイラと開発の道具 | プログラムを作る | 侵入した人が、その場で攻撃用のプログラムを作れる |
| 使っていないサービス（ファイル共有・メールなど） | Web の配信以外の用途 | それぞれの弱点が、そのまま入口になる |
| 書き換えられるシステムの領域 | 設定やプログラムの変更 | 侵入した人が仕掛けたものが、再起動後も残る |
表の上の4行は、管理者が使う道具であると同時に、侵入した人にとっても便利な道具です。Web の配信を受け持つソフトに弱点があって入られたとしても、シェルもソフトを追加する道具も無いサーバーでは、侵入した人にできることは限られます。5行目の使っていないサービスは、取り除けば弱点ごと消えます。一番下の行は、道具やサービスとは違い、書き換えられるシステムの領域についての項目です。OS の中身を読み取り専用にしておけば、仕掛けられたものは再起動で消えます。
ただし、管理の道具を外すと、管理者もそれを使えなくなります。設定の変更や障害の調査を、サーバーにログインせずに行う別の仕組みが要ります。次の章で取り上げる専用の OS は、この仕組みを最初から備えている点で汎用の OS と違います。
作る前に選ぶ、すでにある専用の OS
機能を削った OS は、すでにいくつも公開されています。ここで取り上げる3つはどれもオープンソースで、を動かすことに用途を絞っています。Web サーバーをコンテナとして動かす構成なら、これらをそのままサーバーの OS として使えます。
Sidero Labs 社の Talos Linux は、公式サイトで「SSH なし、シェルなし、パッケージマネージャーなし」とうたっています。サーバーへの操作はすべてで守られた API（決まった形式で命令を受け付ける窓口）を通し、管理者がサーバーにログインすることはありません。入っているプログラムは50個未満で、Kubernetes（多数のコンテナをまとめて管理する仕組み）を動かすのに要る分だけだと説明しています。公式の説明文書によると、OS 本体は読み取り専用の領域から起動し、動作中の作業用ファイルは再起動のたびに作り直されます。再起動をまたいで残すデータは、OS 本体とは別の領域に置く作りです。
AWS の Bottlerocket は、コンテナを動かすのに要るソフトだけを入れた OS です。公式の説明によると、標準の状態では SSH の仕組みもシェルも入っていません。調べ物でシェルが要るときは、標準では無効にしてある管理用のコンテナを有効にして使います。AWS のサーバー管理の機能から命令を送るための制御用のコンテナは、標準で有効です。OS の中身は書き換えられない作りで、dm-verity（ファイルが書き換えられていないかを確かめる Linux の機能）で検証します。AWS のよくある質問によると、更新は一度にまとめて切り替わり、まとめて元に戻すこともできます。
Flatcar Container Linux も、公式サイトの説明では、コンテナの実行に必要なものだけを収めています。公式サイトは、システムの区画を読み取り専用にすることで深刻な弱点の一群を取り除けるとし、OS を小さく単純にすれば攻撃対象領域も小さくなると説明しています。更新は人手を介さずに、一度にまとめて切り替わる方式です。
| OS | 提供元 | 公式の説明にある削ったもの | システムの書き換えへの備え |
|---|---|---|---|
| Talos Linux | Sidero Labs | SSH・シェル・パッケージマネージャー | OS 本体を読み取り専用にし、残すデータは別の領域に置く |
| Bottlerocket | AWS | SSH の仕組みとシェル（標準の状態） | 書き換えられない作りで、dm-verity で検証する |
| Flatcar Container Linux | Flatcar プロジェクト | コンテナの実行に要らないもの | システムの区画を読み取り専用にする |
表の3つはどれも不要な機能を入れない OS ですが、管理の仕方が異なります。Kubernetes で多くのサーバーをまとめて管理しているなら Talos Linux が候補になり、AWS の上でコンテナを動かしているなら Bottlerocket が候補になります。
どれを選ぶ場合も、移る前に、今使っている監視や記録の仕組みがそのまま動くかと、障害のときにログインせずに原因を調べられるかを確かめます。ログインできないことに慣れていない担当者が多ければ、検証用の環境で手順を作ってから本番に移します。
アプリの入れ物も削る、さらにその先の選択肢
OS を削っても、その上で動くコンテナの中に余計なものが入っていれば、入口はそこに残ります。コンテナの中身はとして作ります。よく使われるイメージの中には、汎用の Linux とほぼ同じ道具が入っているものがあります。
Google が公開している distroless のイメージは、アプリとその実行に要る部品だけを収めたものです。公式の説明によると、パッケージマネージャーもシェルも、汎用の Linux にふつう入っているほかのプログラムも入っていません。こうする理由として、弱点を調べる道具（スキャナー）の結果から、関係のない検出が減ること、出どころを確かめる部品が少なくて済むことを挙げています。
入っていない部品の弱点は、そもそも問題になりません。中身が少なければ、古いまま動いている部品を探す作業も楽になります。一方で、シェルが無いので、動いているコンテナに入って調べる従来のやり方は使えません。distroless には調査用にシェルを付けたイメージも用意されているので、障害のときにどちらを使うかを運用の手順に先に書いておきます。
さらに機能を絞る方法として、もあります。代表例の MirageOS は、公式サイトで自らを、ユニカーネルを組み立てるための「ライブラリ OS」と説明しています。できあがったプログラムは単独で完結していて、別の OS を必要とせず、仮想化の仕組み（Xen や KVM）の上で直接動きます。
ユニカーネルは削る考え方を最も先まで進めた形ですが、アプリを専用の道具で組み立て直す必要があります。今の Web サイトをそのまま載せ替えられるものではありません。作り直しの手間を考えると、今動いている Web サイトについては、前の章までの方法を先に検討するほうがよいと考えています。
専用の OS を AI で自作するべきか
AI にプログラムを書かせられるようになり、必要な機能だけを持つ OS を自分たちで作れないか、と考える方もいるはずです。原理のうえでは作れます。OS の中心にあたるの仕事は、プログラムに CPU の時間とメモリを割り当てること、ファイルの読み書きや通信を仲立ちすることです。そこに必要な道具を足していけば OS になります。
問題は作ったあとです。OS の弱点は、公開から何年たっても見つかり続けます。汎用の Linux や前の章の専用 OS では、見つかった弱点を開発者たちが直し、修正を配ります。自作の OS では、弱点を見つけるのも、直すのも、修正をサーバーに配るのも自社の仕事になります。この仕事は、その OS を使い続ける限り終わりません。
AI に書かせたコードは、社内の誰も中身を説明できないまま動き始めることもあります。担当者が交代したとき、説明できる人がいない OS の弱点を誰が直すのかという問いが残ります。既存の専用 OS を選ぶ場合と自作する場合を比べると、次の表のようになります。
| 比べる点 | 既存の専用 OS を選ぶ | 自作する |
|---|---|---|
| 最初の手間 | 移行の検証 | 設計・開発・検証のすべて |
| 弱点を見つける人 | 開発元と世界中の利用者 | 自社だけ |
| 修正を作って配る人 | 開発元が修正を出し、自社は当てるだけ | 自社がすべて行う |
| 担当者が抜けたとき | 公式の文書と利用者の情報が残る | 中身を知る人がいなくなるおそれがある |
| 取引先や監査への説明 | 製品名と公式の文書で説明できる | 説明の資料から自社で作る |
表のうち、年を追うごとに差が開くのは2行目と3行目です。最初の手間は一度で済みますが、弱点を見つけて直す仕事は毎年続きます。利用者の多い OS では、自社が気づかない弱点も誰かが見つけて報告し、修正が出ます。自作の OS では、自社が見つけない限り弱点は残り続けます。
自作が見合うのは、既存の OS ではどうしても満たせない要件があり、修正を続ける人と予算を長く確保できる場合に限られると考えています。多くの会社では、既存の専用 OS を選んで、更新を止めない運用に力を使うほうが、守れる範囲は広くなります。AI に任せたプログラムを公開する前の確かめ方は、AIに作らせた社内ツールを公開前に確かめる7項目にまとめています。
オープンソースを改造して削るときに守ること
自作せずに、既存のオープンソースの OS を改造して要らない機能を削る方法もあります。改造そのものは、オープンソースのライセンスが認める行為です。ただし、ライセンスごとに守るべき義務があり、どの義務が生じるかは、改造したものを社外に配るかどうかで変わります。
Linux のカーネルの利用条件は、GNU GPL のバージョン2（GPLv2）だけです。GPLv2 の第3条は、改造したものを実行できる形で配るとき、対応するソースコード一式を添えるなどの方法で、ソースコードも渡すことを求めています。第2条は、改造したものを配るなら、その全体を GPLv2 の条件で相手に使わせるよう求めています。改造した OS を入れたサーバーをお客様に納める、お客様の機器に入れて渡す、といった形はどれも配布です。
一方で、GPLv2 の第0条は、複製・配布・改変以外の行為は対象外で、プログラムを動かすこと自体は制限しないと定めています。フリーソフトウェア財団の質疑集も、会社が改造したものを社内だけで使い、外に出さないなら公開の義務は無いと答えています。会社の中で複製して使うことも配布にはあたりません。ただし、社外の委託先に渡してその場所で使わせると配布にあたる、とも書いています。
例外は GNU AGPL です。AGPL のバージョン3 の第13条は、改造したプログラムをネットワーク越しに使わせる場合、その利用者全員にソースコードを受け取る機会を目立つ形で示すよう求めています。社外に配らなくても、改造した AGPL のソフトで Web のサービスを提供すれば、この義務が生じます。削る作業の前に、OS に含まれる部品とその上で動かすソフトのライセンスを一覧にしておくと、見落としを防げます。
Apache License 2.0 のソフトには、貢献した人が持つ特許のうち、その人の貢献部分に関わるものの利用も許す条項があります（第3条）。ただし、そのソフトが特許を侵害していると利用者が訴えを起こすと、この特許の許可は失われます。配るときは、ライセンスの写しを渡すこと、変更したファイルに変更した旨を目立つ形で書くこと、元の著作権や帰属の表示を残すこと、NOTICE ファイルがあればその表示を含めることを、第4条が求めています。商標を使う許可は含まれていません（第6条）。
名前も別の問題です。ライセンスがソースコードの改造を認めていても、製品名や商標を使ってよいことにはなりません。Canonical 社の知的財産の方針では、Ubuntu を改造したものを Ubuntu の商標と結びつけて配るには同社の承認が要り、そうでなければ商標を外して置き換えなければなりません。Red Hat 社の商標の方針も、改造したソースコードを配ることは認めつつ、自社の製品から Red Hat の商標をすべて外し、似ていない名前を付けるよう求めています。自社のサーバーだけで使う場合、お客様に配る場合、元の製品名を名乗る場合に分けて義務を並べると、次の表のようになります。
| 場面 | GPLv2（Linux のカーネルなど） | AGPL バージョン3 | Apache License 2.0 |
|---|---|---|---|
| 改造して自社のサーバーだけで使う | ソースコードを渡す義務は生じない | ネットワーク越しに使わせるなら、利用者にソースコードを受け取る機会を示す | 配らなければ、第4条の表示の義務は生じない |
| 改造してお客様に配る・納める | ソースコードも渡す | ソースコードも渡す | ライセンスの写し、変更の表示、帰属の表示を付ける |
| 元の製品名を名乗る | ライセンスとは別に、商標の持ち主の方針に従う | 同じく商標の持ち主の方針に従う | ライセンスに商標の許可は含まれない |
表は、条文と公式の説明から読み取れる一般的な目安です。実際には、1つの OS に異なるライセンスの部品が数多く入っているので、部品ごとに確かめる必要があります。社外に配る予定がある場合や、自社のサービスの中に AGPL のソフトがある場合は、着手の前に弁護士などの専門家に相談してください。
入口の Web サーバーは小さく、データは奥に置く
OS の中身を削るほかに、サーバーの並べ方でも入口を絞れます。インターネットからの通信を最初に受けるサーバー（入口のサーバー）には Web の配信に要る機能だけを載せます。顧客の情報や注文のデータを収めたデータベースは、その奥の、インターネットから直接届かない場所に置きます。
こう並べておくと、入口のサーバーに弱点があって入られても、そこに守りたいデータは置かれていません。侵入した人が奥のデータベースに届くには、もう1つ壁を越える必要があります。入口のサーバーを専用の OS や中身の少ないコンテナで作っておけば、その壁を越えるための道具も手元にありません。
入口から奥への通り道をどこまで絞るか、乗っ取られても全部は取られないように権限をどう分けるかは、次の記事乗っ取られても全部は取られない設計で取り上げます。今のサイトをすぐに分けられない場合でも、入口のサーバーで使っていないサービスを止め、使っていないソフトを消すところからは始められます。
取りかかる順番
ここまでの話を、費用と手間の小さいものから、取りかかる順に並べます。
- 今のサーバーで動いているサービスと、外から届く通信の口を一覧にする
- Web の配信に使っていないサービスとソフトを取り除き、取り除けないものは止める
- コンテナで動かしているアプリは、distroless のような中身の少ないイメージに移す
- OS を入れ替える機会に、Talos Linux・Bottlerocket・Flatcar Container Linux のような専用 OS を候補にする
- 改造や自作は、ここまでで満たせない要件が残ったときだけ考え、ライセンスと商標、修正を続ける体制を先に確かめる
図の左の2段階は、今のサーバーのままで進められます。一覧を作ってみると、誰も使っていないサービスが動き続けていることに気づくかもしれません。引き継いだ Web サイトで最初に確かめる点は、引き継いだWordPressで最初に見る10項目にまとめています。
専用の OS を作るかどうかは、最後に考えれば足ります。多くの場合は、その手前の4段階で攻撃される入口は大きく減ります。AI の登場で破られやすくなった守りの手段については、AIに破られやすくなったセキュリティ対策ランキングで取り上げています。
作った人に聞けないまま動いているサイトや社内ツールを直します
はてなベースでは、会社の WordPress サイトや、AI や外注で作った社内ツールの修正と作り直しを承っています。管理者アカウントの整理、PHP・WordPress・プラグインの更新、二要素認証の設定など、今の仕組みを活かして直せるところから手を付け、直すより早い場合は作り直しをご提案します。