Question 1

クラウド環境において、アプリケーションが利用するIAMロールに、業務上必要な範囲を超えた強い権限(例:全リソースへのフルアクセス)を安易に付与してしまう設定ミスへの対策として、最も適切なものはどれか。

Accepted Answer

必要な操作・リソースの範囲を洗い出し、最小限の権限のみを付与するよう設計を見直す。【解説】クラウド環境のIAM(Identity and Access Management)は、細かな粒度で操作対象や許可する操作を指定できる一方、設定を怠ると意図せず強すぎる権限を付与してしまいやすい。実際に、必要な権限を精査せずフルアクセス権限を持つロールを作成してしまい、そのロールの認証情報が漏えいしたことで被害が拡大したインシデントが数多く報告されている。対策の基本は、そのロールが業務上実際に必要とする操作とリソースの範囲を洗い出し、それ以外の権限は付与しない「最小権限の原則」に基づいて権限設計を継続的に見直すことである。【他の選択肢が不適切な理由】運用の手間を理由にあらゆるロールへフルアクセス権限を一律で付与することは、最小権限の原則に真っ向から反し、1つの認証情報の漏えいが被害範囲を大きく広げる原因になる。権限は事業の変化やロールの用途変更に伴って過剰になっていくことがあるため、一度設定したきり棚卸しを行わない運用は設定ミスの温床となる。強い権限を持つロールほど不正利用時の影響が大きいため、本来は監査ログの記録をより手厚くすべきであり、記録を省略することは適切な対策とは正反対である。

Question 2

クラウド上の各種サービス・リソースの設定内容を継続的に自動収集・分析し、意図しない公開設定やセキュリティ基準からの逸脱を検知して是正を促す仕組みを何と呼ぶか。

Accepted Answer

CSPM(クラウドセキュリティ態勢管理)。【解説】CSPM(Cloud Security Posture Management、クラウドセキュリティ態勢管理)は、クラウド上の各種サービスの設定内容を継続的に自動収集・分析し、意図しない公開設定やセキュリティのベストプラクティスからの逸脱、コンプライアンス違反などを検知して管理者に是正を促す仕組みである。クラウド環境は設定項目が多く複雑になりやすいため、人手による定期点検だけでは見落としが生じやすく、こうした継続的な自動監視の仕組みが重要とされる。【他の選択肢が不適切な理由】CASBは、従業員が利用するクラウドサービスの可視化やデータの持ち出し制御など、利用者側の振る舞いを統制することに主眼を置く仕組みであり、クラウド側の設定状態そのものを継続的に点検する仕組みとは役割が異なる。SIEMは、様々な機器やシステムのログ・イベント情報を集約し相関分析することでインシデントの兆候を検知する仕組みであり、クラウドの設定内容の点検に特化したものではない。IDS/IPSはネットワーク上の通信を監視して不正な侵入を検知・防御する仕組みであり、クラウドの設定内容そのものの点検とは目的が異なる。

Question 3

あるWebサービスのAPIにおいて、リクエストのパラメータに含まれる注文番号を別の値に書き換えるだけで、本来は閲覧できないはずの他の利用者の注文情報が取得できてしまった。このAPIの脆弱性として、最も適切なものはどれか。

Accepted Answer

APIが個々のデータへのアクセス可否を利用者ごとに検証していない、認可制御の不備。【解説】本問のように、APIが受け取った注文番号などのIDを機械的に処理するだけで、その利用者が対象データへアクセスする権限を持つかどうかを個別に検証していない場合、パラメータの値を書き換えるだけで他人のデータにアクセスできてしまう。これは「認可制御の不備」(いわゆるBOLA・IDORと呼ばれる脆弱性)であり、APIを狙った攻撃で最も多く報告される問題の一つとされている。対策としては、APIの各エンドポイントでリクエストのたびに、ログイン中の利用者が対象オブジェクトを操作する権限を持つかをサーバー側で必ず検証することが基本となる。【他の選択肢が不適切な理由】APIキーの有効期限が未設定であることは鍵そのものの管理に関する不備であり、正規の認証情報を使いながら他人のデータへアクセスできてしまう本問の状況の直接の原因ではない。通信経路の盗聴は暗号化(HTTPS化)が不十分な場合に生じる別種の脅威であり、パラメータの書き換えだけで他人のデータを閲覧できてしまう事象とは原因が異なる。リクエスト件数の制限がないことは大量アクセスによる過負荷や不正利用を招く別の問題であり、特定の他人のデータを閲覧できてしまう認可の不備とは性質が異なる。

Question 4

Web APIにおいて、同一の利用者やIPアドレスから短時間に大量のリクエストが送信され、パスワードの総当たり攻撃やサービスの過負荷を招くことを防ぐための対策として、最も適切なものはどれか。

Accepted Answer

一定時間あたりのリクエスト件数に上限を設け、超過した要求は拒否または遅延させる。【解説】APIへの呼び出しを無制限に許可すると、パスワードやAPIキーの総当たり攻撃、あるいは大量のリクエストを送りつけてサービスを機能不全に陥らせる乱用の踏み台にされやすい。こうした乱用を防ぐ基本的な対策が「レート制限」であり、利用者やIPアドレス、APIキーなどの単位で、一定時間あたりに許可するリクエスト件数の上限をあらかじめ定め、これを超えた要求は拒否したり応答を遅延させたりする仕組みである。【他の選択肢が不適切な理由】リクエストを無条件で受け付け件数を制限しないことは、まさに総当たり攻撃や過負荷を許してしまう原因そのものであり対策とは正反対である。認証の仕組みを撤廃し全員が同じAPIキーを共用する状態にすると、誰がどれだけ呼び出したかを区別できなくなり、不正利用者の特定や個別の制限が一切できなくなる。サーバーの台数を増やすことは処理能力の増強にはなり得るが、リクエストの内容そのものを検証しなければ、大量アクセスや不正な呼び出しを見分けて制限することはできない。

Question 5

コンテナイメージの脆弱性スキャンを、本番環境への配置(デプロイ)より前の段階であるCI/CDのビルドパイプラインに組み込む目的として、最も適切なものはどれか。

Accepted Answer

既知の脆弱性を含むイメージを、本番環境へ配置される前の段階で検出し是正するため。【解説】コンテナイメージには、ベースとなるOSのパッケージやアプリケーションが利用するライブラリが含まれており、これらに既知の脆弱性が含まれたまま本番環境へ配置されると、攻撃者に悪用されるリスクを抱えたままサービスを稼働させることになる。そこで、イメージのビルドが完了した段階でCI/CDパイプラインに脆弱性スキャンツールを組み込み、本番環境へ配置される前の早い段階で既知の脆弱性を検出し、深刻なものが見つかった場合はビルドを失敗させて配置を止めるといった「早期発見・早期是正」の考え方(いわゆるシフトレフト)が広く採られている。【他の選択肢が不適切な理由】本番稼働を始めた後にまとめて年に一度だけ確認する方法では、稼働開始から発見までの長い期間、既知の脆弱性を抱えたまま公開され続けることになり、被害が発生するリスクが高い。脆弱性スキャンの主目的はビルド処理の高速化ではなく、むしろスキャン自体にはある程度の処理時間が追加でかかる。脆弱性スキャンはイメージに含まれる既知の脆弱性の有無を確認するものであり、コンテナ起動時のメモリ使用量の見積もりや削減とは目的が異なる。

Question 6

Kubernetes上で稼働させるコンテナのセキュリティを高める実装として、最も適切なものはどれか。

Accepted Answer

コンテナに付与する権限を必要最小限にとどめ、可能な限り非rootユーザーで実行させる。【解説】コンテナは、ホストOSのカーネルを他のコンテナと共有して動作する仕組みであるため、コンテナ内でroot権限や特権(privileged)モードのまま任意のコードが実行されると、コンテナの隔離(分離)が破られてホスト側やほかのコンテナにまで影響が及ぶおそれがある。そのため、コンテナに付与する権限は業務上必要な最小限にとどめ、可能な限り非rootユーザーでプロセスを実行させることや、特権モードを避けることが基本的な対策となる。Kubernetesでは、こうした設定をPodのセキュリティコンテキストやRBAC(役割に基づくアクセス制御)によって強制できる。【他の選択肢が不適切な理由】権限不足のエラーを避けるために全コンテナをroot権限・特権モードで一律起動することは、コンテナが乗っ取られた際の被害をホスト側にまで広げてしまう危険な運用である。クラスタ内の利用者間で権限分離を行わず全員に管理者権限を与えることは、最小権限の原則に反し、誤操作や内部不正による被害の範囲を不必要に広げる。イメージの取得元を検証せず任意の外部レジストリから自由に取得することは、悪意あるコードが混入したイメージを気づかず利用してしまうリスクを高める。

Question 7

CI/CDパイプラインの設定ファイル(ワークフロー定義)内でデプロイ用のクラウド認証情報を扱う方法として、最も適切なものはどれか。

Accepted Answer

CI/CDのシークレット管理機能に登録し、実行時にのみ参照させる仕組みを利用する。【解説】CI/CDパイプラインは、デプロイのためにクラウドの認証情報など強い権限を持つ機密情報(シークレット)を扱う。これらをワークフロー定義ファイルに直接書き込むと、リポジトリを閲覧できる全員に内容が見えてしまい、意図せぬ公開リポジトリ化や画面共有などをきっかけに漏えいする事故につながりやすい。そこで、多くのCI/CDサービスが提供するシークレット管理機能(暗号化して保管し、実行時にのみ環境変数として展開する仕組み)に登録し、設定ファイル自体には値を直接書かないようにすることが基本的な対策となる。【他の選択肢が不適切な理由】認証情報をワークフロー定義ファイルに平文で直接記述しリポジトリで共有することは、閲覧権限を持つ全員に機密情報を晒すことになり、漏えいの典型的な原因である。認証情報を無期限に固定し担当者交代後も更新しない運用は、退職者や異動者が引き続き強い権限を保持し続ける状態を放置することになり危険である。ビルドのログに認証情報をそのまま出力する設定は、ログの閲覧権限を持つ者やログの保存先経由での漏えいリスクを高めるため、多くのCI/CDサービスはむしろ既知のシークレット文字列をログ上でマスキングする機能を備えている。

Question 8

ビルドに用いる外部のオープンソースライブラリやツールを経由して悪意あるコードが混入する、ソフトウェアサプライチェーン攻撃への対策として、最も適切なものはどれか。

Accepted Answer

取得したライブラリやビルド成果物のハッシュ値を検証し、改ざんの有無を確認する。【解説】ソフトウェアサプライチェーン攻撃とは、開発に利用する外部のオープンソースライブラリやビルドツール、あるいはビルド環境そのものを経由して悪意あるコードを混入させ、最終的な成果物を汚染する攻撃である。対策として、外部から取得するライブラリやビルド成果物について、配布元が公開しているハッシュ値やデジタル署名を照合し、通信の途中や配布元での改ざんが行われていないかを検証することが重要である。あわせて、利用しているライブラリの一覧(SBOM)を管理し、既知の脆弱性や不審な変更を継続的に把握できるようにしておくことも有効である。【他の選択肢が不適切な理由】バージョンを固定せず常に最新へ自動更新する運用は、更新の都度中身を検証しなければ、攻撃者が乗っ取った配布元から悪意あるコードを含む新バージョンが自動的に取り込まれてしまう危険がある。外部のライブラリを一切使わない方針は、開発効率やコストの面で非現実的であり、多くのソフトウェア開発はオープンソースの活用を前提としている。ビルド環境へのアクセス権限を制限せず全員に管理者権限を与えることは、最小権限の原則に反し、ビルド環境そのものが攻撃者に乗っ取られた際の被害を拡大させる。

Question 9

開発者のアカウントが乗っ取られた場合や、悪意あるコードが誤って取り込まれた場合に備え、本番環境へ反映される前の段階で検知できるようにする仕組みとして、最も適切なものはどれか。

Accepted Answer

本番ブランチへの変更は、第三者によるコードレビューの承認を経てから反映させる。【解説】開発者のアカウントが乗っ取られたり、悪意あるコードが誤ってリポジトリに取り込まれたりした場合でも、それがそのまま本番環境へ反映されてしまうと被害が実際のサービスに及んでしまう。これを防ぐための代表的な仕組みが、本番ブランチ(mainブランチ等)への変更を、第三者によるコードレビューの承認を経てからでなければ反映(マージ)できないようにするブランチ保護のルールである。レビュー担当者が変更内容を確認する過程で、意図しないコードの混入や不審な変更に気づける可能性が高まる。【他の選択肢が不適切な理由】開発速度を優先して誰もが本番ブランチへ直接コードを反映できるようにすることは、レビューという検知の機会そのものを失わせ、不正なコードの混入を見逃しやすくする。コードレビューの手続きがあっても、内容を確認せず形式的に全て自動承認する運用では、レビューを設けている意味がなく実質的な検知の効果を持たない。契約が終了した退職者のアカウントに反映権限をそのまま残しておくことは、アカウントの不正利用によって本番環境が汚染されるリスクを放置することになる。

Question 10

クラウド事業者が制御コンポーネント(コントロールプレーン)の運用を担うマネージドKubernetesサービスを利用する場合の、責任共有モデルの考え方として、最も適切なものはどれか。

Accepted Answer

制御コンポーネントは事業者が担い、その上で動くアプリの設定や脆弱性対策は利用者が担う。【解説】マネージドKubernetesサービスでは、クラスタ全体を統括する制御コンポーネント(コントロールプレーン、APIサーバーやスケジューラ等)の構築・可用性維持・ソフトウェアの更新といった運用を、クラウド事業者が代行する。一方で、その上で実際に稼働させるアプリケーション(ワーカーノード上のPod)の設定内容、利用するコンテナイメージの脆弱性対策、アプリケーションコード自体のセキュリティ、アクセス制御(RBAC)の設計などは、引き続き利用者側の責任範囲となる。マネージド化によって責任の一部が事業者側へ移る一方、利用者側の責任がすべて無くなるわけではない点を正しく理解することが重要である。【他の選択肢が不適切な理由】マネージド型であっても、アプリケーションの脆弱性対策のような利用者が作成・運用する部分の責任まで事業者が肩代わりするわけではない。逆に、制御コンポーネントの可用性維持は、マネージドサービスを選ぶことで事業者に委ねられる部分であり、利用者が独自に担う必要があるという説明は実態と逆である。責任の分担はIaaS・PaaS・SaaS、あるいはマネージド型かどうかといったサービス形態に応じて変化するものであり、常に一定であるという説明は責任共有モデルの基本的な考え方に反する。

クラウドネイティブ環境のセキュリティ(コンテナ・API・CI/CD)の一問一答