ホストの認証をどう解くか — RACF/ACF2からのID基盤再設計

ホスト移行の計画で最も後回しにされ、しかし切替直前に牙をむくのが認証です。RACFやACF2が担っていたセキュリティは、AWSにそのままは移せません。「資源に対して誰が何をできるか」を軸にしたメインフレームの世界観と、「アイデンティティにロールを与える」現代の世界観は、設計思想が根本から違うからです。

01世界観が違う — 資源中心 vs アイデンティティ中心

RACF/ACF2/Top Secretは、データセットや資源のプロファイルに対して「どのユーザー・グループがどのアクセスを持つか」を定義する、資源中心のモデルです。一方、AWSやモダンなID基盤は、ユーザー（アイデンティティ）にロールを与え、ロールが権限を持つ、アイデンティティ中心のモデル。この向きの違いを理解せずに1対1で移そうとすると、権限の海に溺れます。

02まず棚卸し — 誰が・何に・どうアクセスしているか

移行の第一歩は、現行セキュリティ定義の棚卸しです。

• ユーザーとグループ — RACFのユーザーID、グループ、その階層
• データセット／資源プロファイル — 何が保護され、誰に何の権限（READ/UPDATE/ALTER等）があるか
• バッチの実行ユーザー — ジョブがどの権限コンテキストで動いているか。ここが後述の伏兵
• 特権 — SPECIAL/OPERATIONS等の強い権限を誰が持つか

03バッチ実行ユーザーという伏兵

見落とされがちなのがこれです。メインフレームのバッチジョブは、特定のRACFユーザーの権限で動いています。移行後、そのバッチが読み書きするデータやリソースへのアクセス権を、バッチ実行のサービスアカウント（AWSのIAMロール等）に正しく写せていないと、切替当日にジョブが権限エラーで全滅します。オンラインのユーザー認証に気を取られ、バッチの権限コンテキストを忘れる——これがホスト移行の認証で最も多い事故です。

04写像の設計 — グループ／プロファイルからロールへ

• RACFグループ → ロール — 業務単位のグループは、そのままロールの単位になりやすい
• 資源プロファイル → ロールの権限 — 「このデータセット群にUPDATE」を「この機能／テーブルに対する権限」へ翻訳
• オンラインユーザー → ID基盤へ統合 — 移行先のWeb画面（Angular等）の認証は、既存の社内ID基盤やKeycloakに寄せると、他システムとSSO統合できる

特に、ホスト移行を機に認証をKeycloakのような統合ID基盤に寄せると、移行したシステムが「その1つだけ独自ログイン」の孤島にならず、全社のSSO・多要素認証の傘に入れます。当社はこの統合認証基盤の構築を得意としています（導入事例／関連ソリューション）。

05監査証跡の連続性

金融・自治体系では、「誰が何にアクセスしたか」の証跡が規制要件です。RACFのログ（SMF等）で担保していた監査証跡を、移行後はCloudTrailやアプリの監査ログ、ID基盤のログで切れ目なく再現する必要があります。移行の前後で監査ログが途切れると、その期間の説明責任が果たせません。証跡の連続性は、認証移行の設計に必ず含めてください。

—まとめ

ホストの認証移行は、RACF/ACF2の資源中心モデルを、アイデンティティ中心のモデルへ翻訳する設計作業です。ユーザー・グループ・資源プロファイル・そしてバッチ実行ユーザーを棚卸しし、あるべき権限に整理してロールへ写す。オンライン認証はKeycloak等の統合ID基盤に寄せ、監査証跡は連続させる。「認証は最後に」で計画すると、切替直前にバッチが権限エラーで止まります。ホスト移行の認証は、設計フェーズの主役の1つとして早く着手してください。