参画したときに一度確かめたセキュリティの設定は、そのまま安定して使われ続けると考えられがちです。ところが政府情報システムを対象にしたレポートは、クラウドサービスが頻繁にアップデートされる際に、設定がデフォルト値へ戻ることがあると指摘しています⁴。サプライチェーンのセキュリティは、参画時に一度確かめて終わる仕事ではなく、更新のたびに確かめ直す前提で設計する仕事です。この記事では、その確認をどこで、何度、どう続けるかを、デジタル庁の技術レポートに沿って整理します¹。

1. 参画時に一度確かめて終わる仕事ではありません

一度で終わる確認だと考えると、更新のたびに崩れます

セキュリティ設計の経験を積み重ねてきたエンジニアほど、参画時のチェックリストを一度こなせば守り切れると考えたくなります。設定を確認し、依存するサービスを洗い出し、記録を残す。ここまでを終えれば一区切り、という感覚です。

ところがデジタル庁がまとめたレポートは、サプライチェーン・リスクを動的なものと位置づけ、初回のリスク評価や対策の実施にとどまらず、継続的な監視と再評価を行うことが重要だとしています⁷。新しい機能の導入や既存サービスのアップデートが行われた際には、速やかにリスク評価を更新するプロセスを設ける取り組みが有効だとも述べています⁷。一度きりの確認よりも、確認を繰り返す前提の設計のほうが、更新後のトラブルを防ぎます。

この前提は、案件の途中で担当が交代したときにも関わってきます。確認を一度きりの作業として済ませていると、引き継いだ側は何を、いつ、どこまで確認したのかを読み取れません。確認を繰り返す前提で記録を残しておけば、次に見る人が更新の履歴をたどり直せます。

参画する側としては、確認を一度で終えられると期待されているのか、それとも繰り返す前提で設計してよいのかを、早い段階でクライアントと言葉にしておくと安心です。

レポートの位置づけを踏まえて、確認の粒度を決めます

この記事で参照するのは、2025年6月にデジタル庁が初版を決定した技術レポートです¹。位置づけは参考とするドキュメント（Informative）であり、確認の粒度や頻度は案件やクライアントの体制によって変わります¹。数字で示された基準というより、見落としやすい観点を洗い出すための整理として読むと扱いやすくなります。

参考とするドキュメントであるということは、記載された内容をそのまま契約条件に持ち込めるとは限らないということでもあります。案件で使うときは、レポートの整理を土台にしつつ、実際に確認すべき項目や頻度はクライアントとの協議で具体化する流れになります。

次の章からは、この整理に沿って、参画後に見る領域と、確認をやり直すきっかけになる出来事を順番に見ていきます。

出典：デジタル庁 DS-203（2025年6月）をもとに作成

2. 見る場所は3つの領域に分かれています

レポートは3つの分類で整理しています

確認する範囲を考えるとき、思いつく限り洗い出そうとすると際限がなくなります。レポートはサプライチェーン・リスクを、ビジネスサプライチェーン・リスク、サービスサプライチェーン・リスク、機器・ソフトウェアサプライチェーン・リスクの3つに分類しています²。契約や委託に関わる領域、日々の運用で触れる領域、機器やソフトウェア自体に関わる領域と考えると、担当する案件によって重心が変わることが見えてきます。この記事では、このうちサービスサプライチェーン・リスクを中心に扱います。

この3分類は、レポートがリスクを整理するために用いた区分であり、案件ごとの担当範囲を機械的に決める線引きではありません²。実際の案件では複数の領域にまたがって確認を求められることもあるため、まずはどの分類に近い話をしているのかを揃えるところから始めると、クライアントとの会話がかみ合いやすくなります。

技術的な確認を担うエンジニアの立場からすると、契約や委託の管理に関わる領域まで背負い込む必要はありません。自分が見るべき範囲をサービスサプライチェーン・リスクに絞り込み、残りはクライアント側の担当者と役割を分けて考えると、確認作業の見通しが立てやすくなります。

分類	この記事で扱うか	理由
ビジネスサプライチェーン・リスク	扱いません	契約や委託に関わる領域として別に整理されているため
サービスサプライチェーン・リスク	中心的に扱います	設定・データ消去・依存関係など6項目が含まれるため3
機器・ソフトウェアサプライチェーン・リスク	扱いません	機器やソフトウェア自体に関わる領域として別に整理されているため

サービスサプライチェーン・リスクは6項目に整理されています

サービスサプライチェーン・リスクとして挙げられているのは、役割・責任範囲の理解や認識の不足、クラウドサービスの障害など可用性、適切な設定が実施されないこと、国内法以外の法令や規制が適用されること、データ消去の不確実性、クラウドサービスが利用しているクラウドサービス等に関するリスクの6つです³。

このうち、案件で実際に手を動かす場面が多いのは、設定、依存関係、データ消去の3つです。役割や責任範囲の理解、可用性、法令や規制への対応は、クライアントと協議しながら進める領域として位置づけられることが多く、この記事では設定・依存関係・データ消去の3つを軸に、次の章から順に見ていきます。

まずは設定、依存関係、データ消去の3つから始め、残りはクライアントとの協議で優先順位を決める流れが進めやすくなります。

3. 設定は、更新のときに戻ることがあります

複雑さが、設定を戻りやすくします

確認のたびに、設定したはずの項目が元に戻っている場面に気づくことがあります。うっかりの見落としのように感じますが、レポートを読むと、構造そのものに理由があることが分かります。

レポートは、クラウドサービスは設定項目が多く管理が複雑であること、アクセス制御やネットワーク設定、暗号化設定などがクラウドサービス固有の名称や機能であることが多いこと、そして頻繁なアップデートの際に設定がデフォルト値に戻ることがあることを、その背景として挙げています⁴。設定は一度合わせて終わりではなく、アップデートのあとに合わせ直す作業として組み込む考え方が必要です。

参画するときは、誰が・いつ・どの設定を確認するのかを、更新の予定とあわせて決めておくと、確認が抜け落ちにくくなります。クラウド固有の機能名を都度調べる負担も、確認の手順を先に決めておくことで小さくできます。

確認した結果は、その場で終わらせずに残しておくことも欠かせません。次のアップデートが来たときに、前回どこまで確認していたかが分かれば、差分だけを見比べる作業で済み、確認の手間そのものを減らせます。

出典：デジタル庁 DS-203（2025年6月）をもとに作成

4. 既製品は、共通して使われているぶん広がります

選ばれる理由が、そのまま狙われる理由になります

実績のある既製品を選ぶのは、費用や運用のしやすさを考えると自然な判断です。導入実績が豊富であるほど、情報も集めやすく、安心材料になります。

一方でレポートは、外部調達のソフトウェアは多くの組織で共通して利用されることが多いため、一度脆弱性が発見されると同じ攻撃手法で複数のシステムが攻撃対象となり、攻撃者にとって効率的なターゲットとなりやすいと述べています⁶。導入実績の多さより、その製品が今どこまで検証されているかのほうが、確認の判断材料になります。

見え方	裏側にある意味
多くの組織で共通して利用されている	脆弱性が見つかると、同じ攻撃手法で複数のシステムが攻撃対象になります6
導入実績が豊富で選びやすい	攻撃者にとって効率的なターゲットになりやすいという面もあります6

案件の中でこの視点を持つなら、選んだ理由を「実績があるから」で止めず、脆弱性の情報がどの経路で共有され、どれくらいの速さで反映される体制かまで確認しておくと、既製品を選ぶ判断そのものの精度が上がります。

広く使われている製品を避けるという結論にはなりません。共通利用されていること自体は費用や保守のしやすさにつながる利点でもあります。狙われやすさと利便性の両方を踏まえたうえで、更新情報を追う体制を用意しておくかどうかが、実務での分かれ目になります。

引き継いだ構成を見るときは、導入済みの製品ごとに脆弱性の情報がどこから届くかを先に確かめておくと、対応が後手に回りにくくなります。

5. 使っているサービスも、別のサービスを使っています

依存は一段では終わりません

契約したクラウドサービスの向こう側まで確認するのは、範囲が広すぎると感じられるかもしれません。目の前の契約だけを見ていれば十分だと考えるほうが、作業としては楽です。

レポートは、クラウドサービス自体が他のクラウドサービスや基盤、サードパーティ製ソフトウェアなどを利用していることも多く、これらの相互依存関係が複雑なサプライチェーンを形成しているとし、SaaSプロバイダがIaaSプロバイダのインフラを利用する例を挙げています⁵。確認する対象は、契約した一社にとどまりません。

案件では、契約先に「その先で何を使っているか」を尋ねる場面が出てきます。答えがすぐに得られないこともありますが、入れ子の構造があると知っているだけで、確認を止めるべき層と、掘り下げるべき層の見当がつけやすくなります。

すべての層を自分で調べ切る必要はありません。契約している相手が、その先の依存関係をどこまで把握し、公開しているかを確認できれば、自分が直接調べる範囲と、相手の説明を信頼する範囲の線引きができます。

依存関係を洗い出す作業は、一度で終える棚卸しというより、構成が変わるたびに更新する台帳に近いものです。新しいサービスを追加したタイミングで、その先に何を使っているかを合わせて記録しておくと、次に確認するときの手間が積み上がりません。

出典：デジタル庁 DS-203（2025年6月）をもとに作成

6. 消したはずのデータを、どう確かめるか

「削除しました」を、どう確認してもらうか

案件を離れるとき、データを消去したという説明だけで安心してよいのか迷う場面があります。画面上は消えて見えても、それが確認できる形で証明されているかは別の話です。

レポートはデータ消去の不確実性への対策として、データを暗号化し削除時に暗号鍵を無効化する論理的なデータ消去、外部の監査機関による確認と証明の取得、データ消去プロセスの透明性を重視したクラウドサービスの選定を挙げています⁸。いずれも「消したという説明」ではなく、「消えたことを確かめる手段」に重心を置いた整理です。

3つの手段は、どれか1つを選べば済むものではなく、組み合わせて考える性質のものです。暗号消去の仕組みを備えているか、その説明を外部の監査機関が確認できる形になっているか、選定の段階から透明性を条件にできているかを、順に確かめていく流れになります。

案件の途中でクラウドサービスを乗り換える場面では、この3つの確認が特に効いてきます。移行後に旧環境のデータがどう扱われたかを、契約時点で確かめておかないと、後になって確認する手段そのものが失われてしまうことがあるためです。

手段	内容
論理的なデータ消去（暗号消去）	データを暗号化し、削除時に暗号鍵を無効化します8
外部の監査機関による確認	クラウドサービス提供者に対する監査機関の確認と証明の取得を求めます8
透明性を重視した選定	データ消去プロセスの透明性を選定基準として重視します8

自分が書いていない部分で起きたことも記録されています

自分が直接手を入れていない部分から影響が届いた例も、レポートは事例として整理しています。

2020年12月には、ネットワーク監視製品のアップデートにバックドア型マルウェアが仕込まれ、約18,000の組織が影響を受けた事例が機密性の損失として、2019年12月には、ストレージ装置のファームウェア不具合により全国の複数の自治体で住民票の発行などの行政サービスが停止し、復旧に約1週間を要した事例が可用性の損失として挙げられています⁹。確認を1回で終える判断より、更新のたびに確かめ直す判断のほうが、こうした事態を早く食い止めます。

片方はアップデートに仕込まれたもの、もう片方は装置のファームウェアの不具合によるものです⁹。原因の種類は違いますが、どちらも自分が書いた範囲の外側から影響が届いています。設定と依存関係、データ消去という3つに確認を絞るのは、外側から届く経路を数えられる形にしておくためです。

約18,000という組織数と約1週間という復旧期間は、案件の規模を示す数字ではありません⁹。影響が届く範囲の広さと、可用性が失われたときに元へ戻す作業の重さを示すものとして読みます。

出典：デジタル庁 DS-203（2025年6月）をもとに作成

7. よくある質問

ここまでの確認は、参画後に一人で抱え込む仕事ではありません。よくある質問に沿って、確認の始め方を整理します。

サプライチェーンセキュリティの案件では、具体的に何を確認しますか

案件によって範囲は異なりますが、サービスサプライチェーン・リスクとして整理されている6項目³のうち、設定、依存関係、データ消去の3つに関わる場面が多くあります。参画時にどこまで確認済みかをクライアントとすり合わせておくと、更新後の確認もスムーズに進みます。残りの3項目（役割・責任範囲の理解、可用性、法令や規制への対応）は、クライアント側の体制と合わせて協議する場面が中心になります³。

契約内容の見直しや委託先の評価も担当範囲に入りますか

契約条件の見直しや委託先の評価は、この記事とは別の領域として整理されることが多く、ここでは設定や依存関係、データ消去といったサービス面の確認を中心に扱っています。担当範囲は案件ごとにクライアントと協議して決まります。参画するタイミングで、どこまでが自分の確認範囲になるのかを最初にすり合わせておくと、後から役割が曖昧になる事態を避けやすくなります。

参画したばかりのとき、優先して見ておく範囲はどこですか

まずは自分が触るクラウドサービスの設定が、アップデートのたびにデフォルト値へ戻っていないかを確認する範囲です⁴。あわせて、そのサービスがどんな基盤やソフトウェアに依存しているかを把握しておくと、後のリスク評価の更新が早くなります⁵。この2つを最初に押さえておけば、参画してすぐに全体像を作り直さなくても、更新のたびに差分を確認する形に切り替えられます。

既製品と自社開発のどちらが安全か、優劣を判断できますか

この記事の整理は、どちらが優れているかを判定するためのものではありません。既製品は共通利用されるぶん攻撃対象になりやすい面がある一方で⁶、費用や保守のしやすさという利点もあります。案件で問われるのは優劣の判定よりも、選んだ製品や仕組みについて、更新情報をどう追い、依存関係をどう把握するかという運用の設計です。

こうした案件はRemoguで探せますか

情シスやセキュリティエンジニア向けの案件を扱っており、案件の90%以上がフルリモート可能です¹⁰。案件の傾向は時期によって変わるため、募集内容は都度確認しながら検討を進めてください。この記事で扱った設定の確認や依存関係の把握、データ消去の確認といった経験は、参画時に伝える実績としてそのまま言葉にしやすい強みです。

※公開中の案件数は時期によって変わります。記事中の案件の傾向は執筆時点のものです。

出典・参考情報

＊1 デジタル庁「デジタル社会推進実践ガイドブック DS-203 政府情報システムにおけるサイバーセキュリティに係るサプライチェーン・リスクの課題整理及びその対策のグッドプラクティス集」表紙・改定履歴（2025年6月）
＊2 デジタル庁「デジタル社会推進実践ガイドブック DS-203 政府情報システムにおけるサイバーセキュリティに係るサプライチェーン・リスクの課題整理及びその対策のグッドプラクティス集」2.3／3.1（2025年6月）
＊3 デジタル庁「デジタル社会推進実践ガイドブック DS-203 政府情報システムにおけるサイバーセキュリティに係るサプライチェーン・リスクの課題整理及びその対策のグッドプラクティス集」4.2（2025年6月）
＊4 デジタル庁「デジタル社会推進実践ガイドブック DS-203 政府情報システムにおけるサイバーセキュリティに係るサプライチェーン・リスクの課題整理及びその対策のグッドプラクティス集」4.2 3)（2025年6月）
＊5 デジタル庁「デジタル社会推進実践ガイドブック DS-203 政府情報システムにおけるサイバーセキュリティに係るサプライチェーン・リスクの課題整理及びその対策のグッドプラクティス集」4.2 6)（2025年6月）
＊6 デジタル庁「デジタル社会推進実践ガイドブック DS-203 政府情報システムにおけるサイバーセキュリティに係るサプライチェーン・リスクの課題整理及びその対策のグッドプラクティス集」4.3 1)（2025年6月）
＊7 デジタル庁「デジタル社会推進実践ガイドブック DS-203 政府情報システムにおけるサイバーセキュリティに係るサプライチェーン・リスクの課題整理及びその対策のグッドプラクティス集」3.3（2025年6月）
＊8 デジタル庁「デジタル社会推進実践ガイドブック DS-203 政府情報システムにおけるサイバーセキュリティに係るサプライチェーン・リスクの課題整理及びその対策のグッドプラクティス集」4.2 5)（2025年6月）
＊9 デジタル庁「デジタル社会推進実践ガイドブック DS-203 政府情報システムにおけるサイバーセキュリティに係るサプライチェーン・リスクの課題整理及びその対策のグッドプラクティス集」2章の事例表（2025年6月）
＊10 Remoguサイト公開情報（案件の90%以上がフルリモート可能）