オルタナティブ・ブログ > 経営者が読むNVIDIAのフィジカルAI / ADAS業界日報 by 今泉大輔 >

20年以上断続的にこのブログを書き継いできたインフラコモンズ代表の今泉大輔です。NVIDIAのフィジカルAIの世界が日本の上場企業多数に時価総額増大の事業機会を1つだけではなく複数与えることを確信してこの名前にしました。ネタは無限にあります。何卒よろしくお願い申し上げます。

【緊急共有6】ランサムウェア対策最終回答=AWSゼロトラスト完全実装。社長を説得する前に決めるべき発注先: インドAWS大手4社と国内SIerに任せるべき内容

»

さっつーのAIエージェントを監修している今泉大輔です。昨年後半から今年1月にかけて、アサヒグループやアスクルのランサム被害に対する抜本的な対策を、リサーチャー目線で調査して知見をシェアする経営企画部向けのセミナーを3本やりました。その最後の方「ランサムウェア対策の最終解答:米政府推奨ゼロトラストアーキテクチャ移行の必須知識」(一般社団法人 企業研究会主催。終了セミナーの告知ページは残さない慣行なので今はありません)で配布したA4 100ページの資料、6部から成る内容をアップデートして共有します。これは最終の第6部。誰に何を発注すべきかを論じています。

一連のランサムウェア対策セミナーでは、日本企業が長年怠ってきた社内システムのクラウド化を抜本的に推し進め、その上で、最新のゼロトラストアーキテクチャを実装することが最上の方策である...コストはかかるが...という建付けにして、対策費用を捻出できる立場にある経営企画部の方々にロジックを伝授しました。

緊急共有6:AWSゼロトラスト完全実装.jpg

【レポート本文】

前の報告では、社内システムをAWSに集約し、「誰が、どの端末から、どのシステムとデータに触れてよいか」を一つのルールで揃えるやり方を整理しました。入室の判定、システム同士の確認、データを外に出さない境界、あとから書き換えられないバックアップまでを、同じ土俵に載せる、という内容です。

これを1〜2年でやり切るときに先に尽きるのは、技術の選択肢ではありません。国内で設計と構築を受けられる人数です。(国内SIerの受注キャパシティがなくなるということ。)

本稿は、社長に予算を上げる立場の方向けに、誰に何を頼み、どこまでを国内に残し、どこからを外の工場に出すかを書きます。専門用語は、予算を切るために必要な範囲だけ残しています。

なぜ「誰に頼むか」が先に来るか

ゼロトラストとは、社内ネットワークの中にいるから安全、という前提を捨てる考え方です。人、端末、システム、データを、アクセスのたびに確認します。米国の標準(NIST SP 800-207)と、政府機関向けの成熟度の物差し(CISAのゼロトラスト成熟度モデル)が、この原則の出典です。

AWSに寄せる意味は、この確認を製品ごとにばらばらに持つのではなく、一つのルールとして残せる点にあります。唯一の正解という意味ではありません。AzureやGoogle Cloud、あるいは専用の中継サービスでも、同じ原則は実装できます。ただしルールの置き場所が分かれると、監査のときに「どこで止めたか」を説明しにくくなります。AWSに集約するのは、説明責任を一箇所に寄せるための選択です。

先に決めるべきは供給です。被害が重なると、同じ種類の引き合いが主要な国内ベンダーに同時に入ります。既存の基幹を理解したうえで、新しい境界まで設計できる国内人材は少なく、提案と設計の枠は数ヶ月で埋まります。予算の総額より、どの枠をいつ確保するかが、着手できるかどうかを分けます。

仕事を五つに分け、残すものと出すものを決める

頼む仕事は次の五つです。それぞれに、国内に残すものと、外の工場に出してよいものを置きます。

一つ目は、方針・監査・経営報告です。これは国内に残します。既存の契約とのつなぎ、監査法人への説明、取締役会への報告は、社内の経緯を知らないと遅れます。外に出してよいのは、決まった方針を作業指示と完了条件に翻訳する部分だけです。

二つ目は、現行システムの棚卸しと、載せ替え方の判断です。これは共同でやります。何をそのまま移し、何を作り替えるかは、止まったときの事業影響を見て国内が決めます。調査の実働と、移行手順への落とし込みは、人数を出せる側に出します。

三つ目は、確認ルールの設計です。誰を認めるか、どの端末なら通すか、システム同士をどう認証するか、データをどの範囲から出さないか。骨子は国内が書き、実装の型は工場が作ります。骨子が週の途中で揺れると、工場は待ち時間だけを消費します。

四つ目は、構築・移行・復旧環境です。ここは工場に出す比重を高くします。あとから消せないバックアップと、侵害されてもそこから戻せる隔離環境は、並行して人数を投入できる側が有利です。

五つ目は、運用の引き継ぎと、社内で回せる状態にすることです。これは国内に戻します。日本語の手順と、障害時に誰が電話を受けるかが残らないと、移行が終わったあとに止まります。

誰に何を持たせるか

国内の主契約ベンダー(いわゆるプライムSIer)には、要件の確定、既存システムの理解、監査対応、日本語の窓口、長期の運用契約を持たせます。構築の全量まで期待すると、枠が先に尽きます。

AWSには、標準的な設計例、サービス仕様、技術サポート、ソフトウェアを調達する窓口(マーケットプレイス)を使います。設計の責任主体にはしません。部品の名前だけ先に置きます。入室判定はVerified Access、システム同士の確認はVPC Lattice、社員の認証を後ろのシステムまで渡す仕組みはIAM Identity Center、データを組織の外に出さない境界はResource Control Policies、消せないバックアップはBackup Vault Lockです。予算審議では、この五つの有無を見れば足ります。

端末が安全な状態か、強い権限を誰が持っているかは、AWSとは別の専門ベンダーに分けます。入室のルールだけAWS側で揃えて、端末と強い権限を残すと、確認が途中で欠けます。端末の状態は、CrowdStrike(感染や不正の有無)、Microsoft Intune(会社支給のWindows端末などの設定と合格条件)、Jamf(Apple端末の管理)が担います。強い権限の保管と、必要なときだけ払い出す仕組みは、CyberArkなどの特権管理ベンダーが担います。これらは前稿で、AWSの入室判定と連携する前提の相手です。AWSの利用料とは別に、この層の契約を一行入れてください。

インドのAWS大手4社は、移行と実装の工場として使います。TCS、Infosys、Wipro、HCLTechの四社で、いずれもAWSの最上位パートナーです。英語の技術資料を作業手順に落とす速度と、複数の案件へ同時に人数を出す厚みが、国内よりあります。TCSは基幹システムを含む移行の量、Infosysはアプリケーションの作り替え、Wiproは移行を工場として回す体制、HCLTechは移行から運用までの型に、それぞれ厚みがあります。東欧や南米にも同水準の会社はありますが、AWSの認定者数と並行して受けられる件数では、この四社が厚いです。

避けたい頼み方は二つです。方針まで含めて一社に丸投げすることと、国内だけで量を賄おうとすることです。前者は仕様が定まらず、後者は枠が先に尽きます。

予算を付けるときの二つの型

型Aは、国内に方針と監査を残し、移行とルール実装の量をインドの工場に出す形です。既存の説明責任を残したい会社向けです。データは東京または大阪のAWS拠点に置き、社長決裁で工場の発注枠だけを先に確保できる場合に、再現性が高いです。

型Bは、インド側を準主管にし、国内は進捗管理と監査だけ残す形です。速度を優先し、社内に技術判断ができる人材がいる場合に限られます。業務の暗黙知が厚い、または規制対応で説明の相手が多い場合には向きません。

見る点は四つです。止まったときに何時間で戻したいか。残したい社内のスキルは何か。データをどの国内拠点に置くか。決裁に何週間かかるか。決裁が遅いと、どちらの型でも工場の枠が先に他社へ埋まります。

1〜2年の進め方と、各期に受け取るもの

最初の半年は、人とデータの境界です。国内が「誰を、どのデータまで」の方針を書きます。工場が認証の統合と、データを外に出さないルールを実装します。AWSが仕様とサポートで裏付けます。受け取るものは、統合した認証の範囲と、データの境界の一覧です。

次の半年は、社外からでも同じ基準で入室できる状態です。国内が、端末の合格条件を固定します。工場が、その条件で入室を判定するルールを展開します。受け取るものは、入室ルールの一覧です。

その次の半年は、システム同士の確認と、戻せる環境です。国内が、先に守るシステムの順番を切ります。工場が、システム間の認証と、隔離した復旧環境を作り、戻せることを試験して記録します。受け取るものは、試験結果です。

最後の半年は、自動での是正と、運用の引き取りです。国内が運用基準を持ちます。工場が、ルールをプログラムとして残し、逸脱を自動で直す仕組みを渡します。受け取るものは、監査に出せる記録です。

途中で止まりやすい点と、先に防ぐこと

国内の窓口が仕様を固定できないと、工場が空転します。変更を入れてよい日を週に一度と決め、それ以外は受け付けない、と契約に書きます。

日本語の手順を後回しにすると、引き継ぎで止まります。各期の完了条件に、手順書と権限の一覧の日本語化を入れます。英語の成果物だけを完了と認めない、と書きます。

システムをAWSに移したことを完了と誤認すると、入室ルールと端末の確認が残ります。五つの部品ごとに、実装済みと未了を分けて報告させます。移設の完了を、ゼロトラストの完了と同一視しないでください。

費用を、従来のシステム更新と同じ感覚で置くと、途中で縮小します。方針を持つ国内、量を出す工場、復旧環境、端末と特権の専門ベンダー、の四行に分けて予算を置きます。縮めるときは、どの行をどの範囲で切るかを明示します。前稿で触れたとおり、制御面まで揃える費用は、従来の更新の数倍になり得ます。この倍率を隠すと、期の途中で止まります。

経営企画が切る依頼と、最初の90日で見ること

依頼書で切る項目は四つです。揃えるルールの範囲。工場側のAWS最上位認定と、同種の移行実績。日本語で橋渡しできる人数と、その人数が常駐か遠隔か。成果物の帰属(手順、ルールのプログラム、試験記録を、発注者に渡すこと)。人月単価だけでは、空転と引き継ぎ失敗を見分けられません。

最初の90日で見る数字は三つです。棚卸しが終わったシステムの割合。認証を一つに統合した利用者の範囲。ルールをプログラムとして残した件数。この三つが動かなければ、技術の議論を続ける前に、体制を組み替えます。

前の報告で述べた、有事としての社長決裁は、ここでも前提です。工場の枠は、引き合いが重なると先に埋まります。技術の詳細がすべて揃ってから発注するのでは、供給の制約に間に合いません。予算を分ける単位は、方針を持つ国内と、量を出す工場です。

供給が先に尽きる前提では、国内に方針と監査を残し、実装の量をインドのAWS大手4社に出す形が、いま再現しやすい答えです。技術の全体像は前稿、予算と役割の切り方は本稿、と分けて使ってください。

Comment(0)