クラウドセキュリティの基礎

クラウドセキュリティの基礎

自社で購入したサーバーを自社内に設置する「オンプレミス」環境では、ハードウェアの設置場所から物理的な施錠、ネットワーク機器の設定、OSのセキュリティ対策まで、すべてを利用企業自身が管理します。一方、AWS・Azure・GCPのようなパブリッククラウド上にLinuxサーバー（仮想マシンのインスタンス）を構築する場合、物理的なデータセンターやハードウェアの管理はクラウド事業者が担い、その上で動くLinux OSやアプリケーション、データの管理は利用企業（ユーザー）が担う、という形でセキュリティ対策の責任が両者に分かれます。

この「どこまでを事業者が守り、どこからを自分たちで守るのか」という役割分担を理解しないまま運用すると、「クラウド事業者が全部守ってくれているはず」という思い込みでOS側の対策を怠ったり、逆に「事業者側の機能を使えば十分」と誤解して本来必要な設定を見落としたりする事故につながります。LinuCレベル1では、このうち「パブリッククラウド上にLinuxサーバーを構築して使う」という最も基本的な形態（IaaS）を前提に、事業者側の管理機能とLinuxサーバー側の機能がそれぞれ何を担うのかを、次の5つの観点から理解することを求めています。

• 管理機能の分担（管理コンソール・ファイアウォール・ルーティング）
• リージョン選択
• 揮発性ストレージの取り扱い
• 事業者側の都合によるメンテナンス・再起動
• 管理コンソールへのアクセス経路と認証方式

IaaS/PaaS/SaaS

クラウドサービスは、事業者が管理する範囲によって次の3種類に分類されます。

責任共有モデル

クラウドの安全性は、クラウド事業者と利用者が分担して確保するという考え方です。

利用者の管理範囲は、一般に IaaS → PaaS → SaaS の順に小さくなります。なお、責任範囲の詳細は、クラウド事業者の契約やサービス仕様で確認が必要です。

パブリッククラウドの管理機能とLinuxサーバーの機能分担

管理コンソール：クラウド事業者が提供する管理用の窓口

管理コンソール（マネジメントコンソールとも呼ばれます）は、クラウド事業者が提供する、Webブラウザやコマンドラインツール・APIを通じてクラウド上のリソース（仮想マシン、ストレージ、ネットワークなど）を作成・設定・監視するための管理用の窓口です。オンプレミス環境で物理サーバーやネットワーク機器に直接触れて設定していた作業の多くを、クラウドでは管理コンソールを経由して行うことになります。

管理コンソールは、個々のLinuxサーバー（インスタンス）にログインしなくても、契約しているクラウド環境全体の設定を変更できてしまう強力な窓口です。この管理コンソール自体を安全に保つことの重要性は、後述の「認証方式」で扱います。

ファイアウォール：クラウド側とOS側の二重の防御

クラウド環境でのファイアウォールには、大きく分けて2つの層があります。

• クラウド側（ネットワーク層）のファイアウォール：管理コンソールから設定する、仮想ネットワークの入口・出口を制御する機能です。例えば「セキュリティグループ」「ネットワークACL」などがありますが、これらは事業者による名称の違いだけではなく、適用単位やステートフル／ステートレスといった動作も異なります。どのIPアドレス・ポートからの通信をLinuxサーバーへ到達させるかを、OSの外側で制御します。
• OS側（Linuxサーバー内部）のファイアウォール：Linuxサーバーにログインして設定する、従来からあるiptables・nftables・firewalldなどの機能です。

この2つは互いに独立した仕組みであり、どちらか一方で通信を遮断していれば、通信は到達しません。例えばクラウド側のファイアウォールで特定のポートへの通信を許可していても、OS側のファイアウォールでそのポートを塞いでいれば通信は届きませんし、逆にOS側をすべて許可していてもクラウド側で遮断されていれば外部からは到達できません。両方の層で必要最小限の通信だけを許可するという考え方（多層防御）は有効ですが、OS側のファイアウォールを利用するかどうかは、クラウド側のアクセス制御や運用要件を踏まえて判断します。

ルーティング：仮想ネットワーク内の通信経路の制御

ルーティングも同様に、クラウド側（仮想ネットワークのルートテーブル）とOS側（ip routeコマンドなどで確認・設定する経路情報）の両方に存在します。クラウド側のルーティング設定では、例えば「インターネットへの出入り口となるゲートウェイを経由させるか」「他の仮想ネットワークやオンプレミス環境への専用の経路を使うか」といった、仮想ネットワーク全体の通信経路を管理コンソールから制御します。Linuxサーバー自体はオンプレミスの物理サーバーと同じOSであるため、OS内部のルーティングの考え方自体はオンプレミスと変わりませんが、その通信が実際にどこへ届くかは、クラウド側のルーティング設定にも左右されるという点を理解しておく必要があります。

リージョン選択（国内外の制約を含む）

クラウド事業者は、世界各地・国内複数箇所にリージョンと呼ばれる、地理的に離れた独立したデータセンター群を用意しています。あるリージョンで大規模な障害が発生しても、地理的に離れた別のリージョンには影響が及びにくいという特徴があります。

パブリッククラウドでLinuxサーバーを構築する際には、どのリージョンを選ぶかによって、次のような違いが生じます。

• 適用される法令・データの持ち出し制約：データの種類によっては、法令によって国外への持ち出しが制限されている場合があります^{どのようなデータがどの法令の対象になるかは、業種・データの性質・利用者の所在国によって異なります。「クラウドを使う以上は必ず国内リージョンを選ばなければならない」という一律の話ではなく、扱うデータの性質に応じて確認が必要な事項です。[1]}。海外リージョンを選ぶ場合は、機密データが物理的に国外のデータセンターに保管されることになる点や、その国の法制度（捜査機関によるデータ開示要求の仕組みなど）も考慮する必要があります。
• 通信のレスポンスタイム（レイテンシ）：一般的に、利用者やアクセス元から地理的に近いリージョンほど、通信の往復にかかる時間（レイテンシ）は短くなる傾向があります。国内の利用者が主な対象のサービスであれば、国内リージョンを選ぶ方が応答性能の面で有利になりやすい傾向があります。
• リージョンごとの安定性・提供機能の違い：リージョンによって、利用できるサービスの種類や、実績・安定性が異なる場合があります。新しく開設されたリージョンでは、他のリージョンで使える一部の機能がまだ提供されていないこともあります。

これら3つの観点（法令・レイテンシ・リージョンごとの違い）は、単独で決まるものではなく、扱うデータの性質やサービスの利用者層に応じて総合的に検討する必要があります。

パブリッククラウドの揮発性ストレージ

パブリッククラウドの仮想マシンには、揮発性ストレージ（エフェメラルストレージ、インスタンスストアなどと呼ばれます）と呼ばれる、一時的な用途向けのストレージが用意されている場合があります。これは、その仮想マシンが稼働している物理ホストに直結した記憶装置を割り当てたもので、ネットワーク越しにアクセスする永続的なストレージ（クラウド事業者によって「ブロックストレージ」「永続ディスク」などと呼ばれます）と比べて高速に読み書きできることが特徴です。

その一方で、揮発性ストレージに保存したデータは、仮想マシンの停止や終了、稼働している物理ホストの切り替えなどのタイミングで失われることがあります^{例えばAmazon EC2のインスタンスストアについては、公式ドキュメントで、再起動の場合はデータが保持される一方、停止・休止・終了や基盤ディスクの障害時にはデータが失われる、という具体的な挙動が説明されています（参考情報参照）。「再起動でも必ずデータが消える」というのは誤りで、どのタイミングでデータが失われるかは事業者・イベントの種類によって異なります。ここでは「消えないことを前提にはできない」という共通点を押さえておくことが重要です。[2]}。この特性を理解せずに、データベースの永続データや業務上失ってはいけないファイルを揮発性ストレージだけに保存してしまうと、意図しないタイミングでデータを失う事故につながります。揮発性ストレージは、キャッシュや一時的な作業領域、再生成可能なデータなど、失われても業務上問題にならない用途に限定して使い、恒久的に保持したいデータは永続的なストレージ側に保存する、という使い分けが基本になります。

クラウドサービス事業者の制約による管理（メンテナンス、再起動）

オンプレミス環境では、サーバーの再起動やハードウェアのメンテナンスを行うタイミングは、基本的に自社の都合で決められます。しかしパブリッククラウドでは、物理ハードウェアそのものはクラウド事業者が管理しているため、事業者側の都合によるメンテナンスや、予期しないハードウェア障害への対応によって、利用者側のLinuxサーバー（インスタンス）が再起動されたり、一時的に停止・移動したりする可能性があります。

こうしたメンテナンス・再起動は、事前に予告されたスケジュールに沿って行われる場合と、ハードウェア障害への緊急対応のように予告なく発生する場合があります^{メンテナンスの予告方法・猶予期間・自動での再起動の有無などは、クラウド事業者・契約プラン・サービスの種類によって異なります。「予告メンテナンスなら必ず数日前に通知される」といった一律の運用を前提にはできません。[3]}。利用者側では、こうした事業者都合の再起動・停止が起こり得ることを前提として、前述の揮発性ストレージだけに失われてはならないデータを保存しない、複数の仮想マシンで冗長構成を組むといった備えが必要になります^{具体的な冗長構成の設計手法（複数リージョンにまたがる構成、フェイルオーバーの仕組みなど）は、より上位のシステムアーキテクチャに関する内容のため、本記事では扱いません。[4]}。

パブリッククラウドの管理コンソールへのアクセス経路と認証方式

インターネット経由でのアクセスと事業者提供の認証方法

パブリッククラウドの管理コンソールは、多くの場合、社内ネットワークなどの閉じた回線からではなく、インターネットを経由してアクセスするWebサイト・APIエンドポイントとして提供されています。これは、管理者がどこからでも管理作業を行えるという利便性がある一方で、インターネット上の誰もがログイン画面にアクセスできる状態にあるということでもあります。

管理コンソールへのログインには、Linuxサーバー自体のOSアカウント（/etc/passwd等で管理されるユーザー）とは別に、クラウド側のID管理基盤が使われます。クラウド事業者が提供するIAMのアカウントを使う場合のほか、企業が管理する外部のIDプロバイダと連携したフェデレーションやSSOを使う場合もあります。この管理コンソール用アカウントが第三者に不正利用されると、個々のLinuxサーバーへの侵入とは比べものにならない範囲（契約しているクラウド環境全体のリソースの作成・削除・データの閲覧など）に被害が及ぶおそれがあるため、Linuxサーバー自体のセキュリティ対策と同等以上に、管理コンソール側のアカウントを保護することが重要になります。

多段階認証・多要素認証・ワンタイムパスワード

管理コンソールのようにインターネット経由でアクセスできる窓口を保護する代表的な方法が、IDとパスワードだけに頼らない追加の認証手段を組み合わせることです。

• ワンタイムパスワード（OTP）：一定時間だけ有効な、あるいは一度使うと無効になる使い捨てのパスワードです。認証アプリで生成・表示される場合や、事業者から送信されるメッセージなどを通じて、ログインのたびに新しい値を利用します。
• 多要素認証：「知識情報（パスワードなど、本人だけが知っていること）」「所持情報（スマートフォンやハードウェアトークンなど、本人だけが持っているもの）」「生体情報（指紋や顔など、本人自身の特徴）」という異なる種類の要素を2つ以上組み合わせる認証方式です。パスワード（知識情報）に加えて、登録済みのスマートフォンに送られるワンタイムパスワード（所持情報）を入力させる方式が代表例です。
• 多段階認証：認証を複数の段階（画面）に分けて行うことを指す、やや広い意味の言葉です。多要素認証は異なる種類の要素を組み合わせますが、多段階認証という言葉には、同じ種類の要素を用いる複数の認証手順を含む用法もあります。そのため、「段階が多い＝要素の種類が異なる」とは限らず、要素の種類まで異なっているかどうかが、認証強度を考えるうえでのポイントになります^{「多段階認証」と「多要素認証」の呼び分け方は情報源によって幅があり、両者をほぼ同じ意味で使う資料もあります。ここでは「段階を分けること」自体と「要素の種類を変えること」は別の観点であるという点を押さえておいてください。[5]}。