クラウドサービス利用時のセキュリティ設計
AI生成の参考答案（架空）
問題・答案ともに独自教材です。実際のIPA過去問・公式解答ではありません。年度・季節は教材の整理用ラベルです。論述構成を学ぶために過去問AIが生成した架空の参考例で、合格を保証するものではありません。論述の骨格・業種事例の参考としてご活用ください。
問題概要
近年、多くの組織がクラウドサービスへのシステム移行を進めている。クラウドサービスの利用においては、クラウド事業者と利用者の間の「責任共有モデル」を正確に理解した上で、利用者側のセキュリティ対策を適切に設計しなければならない。具体的には、IAM（Identity and Access Management）による最小権限の実装、データの暗号化と鍵管理、ログの取得と保管、ネットワークのセグメンテーション、及びマルチクラウド・ハイブリッド環境における統合管理が求められる。
全文を表示
業種を選択してください
IT・情報サービス業の参考答案例
約 1,945 字序論（設問ア）
私が情報セキュリティアーキテクトを務めるF社は、中堅のSaaSプロバイダである。従業員数約300名で、製造業・小売業向けにERPクラウドサービスを提供している。顧客データをマルチテナント構造で管理しており、クラウドセキュリティの設計品質が事業の信頼性に直結する。 2023年秋、F社では新たにAWSへの基盤移行プロジェクトが承認された。既存のオンプレミス基盤から全面的にIaaSへ移行し、サービスのスケーラビリティと可用性を向上させる計画である。私はクラウドセキュリティ設計の責任者として、移行時のセキュリティアーキテクチャ設計と実施を担当した。本稿では、その取り組みについて述べる。 オンプレミスからIaaSへの移行に際し、F社が直面したセキュリティ上の主要課題は三点あった。第一に、オンプレミス環境では境界型防御（ファイアウォール＋VPN）を前提とした設計であり、クラウド環境の「境界がない」モデルへの適応が必要だった。第二に、マルチテナントSaaSとして顧客データの論理分離を維持しながら、クラウドネイティブのIAM（Identity and Access Management）を適切に設計する必要があった。第三に、クラウド環境の設定ミス（Misconfiguration）が直接的なセキュリティホールになるリスクへの対処が求められた。
本論（設問イ）
私はクラウドの責任共有モデルを基に、利用者が設計・運用する範囲を整理した。 アーキテクチャの第一の柱は、最小権限IAMの徹底設計である。AWSのIAMポリシーを全サービス・全ロールに対して「拒否ルールファースト」で設計し、業務上必要最小限の権限のみを許可するAllow文を付与した。本番環境へのデプロイ権限は人間のオペレータには付与せず、CI/CDパイプライン専用のIAMロールのみが持つ「人手不要デプロイ」設計を採用した。開発者が本番環境のリソースに直接アクセスが必要な場合は、AWS Systems ManagerのSession Manager（パスワードレス・VPN不要）経由とし、セッションログをS3に自動保存する構成とした。 第二の柱はテナント分離である。RDSのスキーマをテナント別に分け、DBロールとGRANTで参照範囲を制限した。接続プールが別テナントの認証情報を再利用しないこともテストした。IAMタグはRDS内の行やスキーマを認可する機能ではない。アプリのテナント判定に加えてDB側でも制限し、他テナントIDやSQLを指定した試験で拒否を確認した。S3もテナントごとのバケットとIAMロールで分けた。 第三の柱は、クラウド設定ミス（Misconfiguration）の継続的検知体制の構築である。AWS SecurityHubとAWS Configを組み合わせ、設定変更をリアルタイムで記録・評価する仕組みを導入した。S3バケットのパブリック公開、セキュリティグループの0.0.0.0/0許可、CloudTrailの無効化、などを高リスク設定として定義し、発生時は即時Slackアラートを発報する自動化を実装した。月次でAWS Well-Architectedレビューのセキュリティピラーを担当者が確認するサイクルも設けた。 第四の柱は、Secrets Managementの一元化である。データベースパスワード・外部APIキー・暗号化キーをAWS Secrets Managerに集約し、アプリケーションがハードコードや設定ファイルへの直接埋め込みをできない設計に変更した。秘密情報のローテーションは自動化し、期限切れや漏洩時の影響範囲を最小化した。 移行プロジェクトの推進にあたり、開発チームから「新しいIAM設計でローカル開発環境の構築が複雑になる」との懸念が出た。私は開発者向けのAWS SSOを整備し、個人のAWSアカウントと本番IAMロールを明確に分離した開発環境テンプレートを提供した。設計の複雑さをツールで吸収することで、開発者体験を損なわずセキュリティを確保できた。
結論（設問ウ）
移行後6か月間、クラウド設定ミス起因のセキュリティインシデントはゼロを達成した。SecurityHubのセキュリティスコアは移行前比で31ポイント向上し、顧客向けセキュリティホワイトペーパーにも成果を反映できた。 残存課題として、サードパーティSaaSとのOAuth連携に使用するアクセストークンの管理が不十分であり、Secrets Managerへの統合が一部残っている。また、複雑なIAMポリシーの可読性・保守性の低下がリスクとして顕在化してきており、IAM Access Analyzerと自動テストを組み合わせたポリシー品質管理フレームワークの整備を次期課題として位置づけている。
試験制度・公式過去問の確認: IPA 情報処理技術者試験
金融業の参考答案例
約 1,846 字序論（設問ア）
私はG証券会社（口座数約180万件、従業員数約2,200名）の情報セキュリティ部に所属し、社内システムおよびクラウド基盤のセキュリティ設計を担当している。証券会社は個人・法人の有価証券情報・口座情報・取引データという高度な機密情報を扱い、金融商品取引法・金融庁のシステムリスク管理態勢に関する監督指針への対応が必須である。 2023年度、G証券では既存の社内業務系システム（メール・ファイル共有・ERP）を主要クラウドサービス（Microsoft 365・Azure・Salesforce）へ移行するプロジェクトが開始された。私はクラウド移行のセキュリティアーキテクトとして、金融規制に対応したクラウドセキュリティ設計を担当した。本稿ではその取り組みを述べる。 G証券のクラウド移行において、セキュリティ設計上の課題は三点あった。第一に、金融庁のシステムリスク管理指針では「主要な情報システムに係るリスク管理が実効的に機能していること」が求められ、クラウドサービスのリスク評価を自社の監督下に置く体制が必要だった。第二に、オンプレミス環境では確立していた境界型セキュリティが、クラウド環境では適用できないため、クラウドネイティブなセキュリティ制御を新たに設計する必要があった。第三に、Azure ADとオンプレミスのActive Directoryを共存させるハイブリッド構成での権限管理の複雑性に対処しなければならなかった。
本論（設問イ）
私は社内の業務・法務・運用担当者と責任分界を確認し、次の構成を設計した。 第一の柱はサービスごとの責任分界の文書化である。Microsoft 365、Azure、Salesforceそれぞれについて、当社と提供者が担う設定・更新・バックアップ・障害対応を整理した。データ保存先だけでなく、国外からの保守アクセスと再委託先も確認し、当社に必要な安全管理、監査証拠の取得、終了時のデータ返却を契約で明確にした。チェックリストと残るリスクを情報セキュリティ委員会へ報告した。 第二の設計柱は、条件付きアクセスポリシーによる境界の再構築である。Azure AD（Entra ID）の条件付きアクセスを全ユーザ・全クラウドアプリに適用し、「社有端末」「多要素認証」「金融コンプライアンスPCポリシー準拠端末」という三条件を全て満たす接続のみを許可した。個人端末・未管理端末からの業務アクセスをシステム的に遮断し、クラウドサービスへのアクセスポイントを管理下に置いた。 第三の設計柱は、情報保護（Microsoft Purview）の実装による機密データ管理である。顧客個人情報・取引情報・社外秘に該当するファイルを自動分類し、ラベルに応じた保護アクション（外部共有禁止・暗号化・保存先制限）を適用した。SharePointおよびTeamsでの外部共有は、金融コンプライアンス部門が管理する承認済みドメインリストに基づき制御した。 第四の設計柱は、Microsoft SentinelによるSOC（Security Operations Center）の強化である。Microsoft 365・Azure・Salesforceの監査ログをSentinelに集約し、不審な管理者権限の変更・大量データエクスポート・非業務時間の特権アクセス、などに対するアラートルールを整備した。SOC担当者が一画面でクラウド全体のセキュリティイベントを把握できる環境を構築した。 金融規制対応では、Salesforceのデータ保存先が日本国内に限定されているか、越境移転が発生する場合の根拠規定は何かを確認し、金融庁の外部委託先管理基準に適合することを確認した上で導入した。一部のAzureサービスで日本リージョンにないサービスがあり、代替設計で対応した。
結論（設問ウ）
クラウド移行完了後、金融庁への事前報告した内容と実際の移行後状態が整合しているか確認する内部監査を実施し、適合を確認した。条件付きアクセスの適用で、未管理端末からのクラウドアクセス試行が週平均42件検知・遮断されており、未整備のまま移行した場合のリスクが定量的に示された。 残存課題として、Salesforceのカスタムアドオンがデータを外部エンドポイントに送信する可能性があり、サードパーティAppExchangeの審査プロセスの厳格化が必要である。また、Sentinel運用の人員コストが想定を超えており、自動応答（SOAR）の活用でアラート対応の効率化を進める方針である。
試験制度・公式過去問の確認: IPA 情報処理技術者試験
建設業の参考答案例
約 1,739 字序論（設問ア）
私はH建設株式会社（売上高2,700億円、従業員数2,100名）の情報システム部でセキュリティ担当を務めている。H社はBIM（Building Information Modeling）を全面活用した設計・施工管理をコア競争力とし、建築・土木の両事業を展開している。2023年度、H社では全社のBIMプラットフォームおよびプロジェクト管理ツールをクラウド環境（Autodesk Construction Cloud・Microsoft Azure）へ移行するプロジェクトが開始された。 建設業ではBIMモデルに設計ノウハウ・積算単価・施工計画という高度な営業秘密が凝縮されており、クラウド移行時のセキュリティ設計は事業競争力の保護に直結する。私はクラウドセキュリティ設計の責任者として、本移行プロジェクトに参画した。 H社のBIMクラウド移行に際し、セキュリティ設計上の課題は三点あった。第一に、設計データ・積算データは「極秘」相当の営業秘密であり、クラウドサービス側のデータアクセス制御の設計精度が直接的な競争リスクと直結していた。第二に、協力会社（設計事務所・専門工事業者）がBIMデータにアクセスする場面が多く、外部ユーザへの権限付与設計が複雑だった。第三に、現場端末（タブレット・ノートPC）はネットワーク環境が不安定な建設現場で使用されるため、オフライン時の制御も考慮する必要があった。
本論（設問イ）
私はBIM運用担当者と協力会社の責任者を交え、以下の構成を設計した。 第一の設計柱は、Autodesk Construction Cloudにおけるプロジェクト分離と権限設計である。プロジェクトごとに「社内設計チーム」「社内施工チーム」「協力会社設計事務所」「専門工事業者」の四つのロールを定義し、ロールごとのアクセス可能フォルダ・ダウンロード権限・外部共有可否を細かく設定した。特に積算データ（原価情報）を含むフォルダは「社内設計チーム長以上」のみ閲覧可能とし、他ロールへの誤公開を防ぐ厳格な分離を実装した。 第二の柱は外部ユーザーの管理である。協力会社ごとに個人のゲストIDを発行し、担当工事の終了予定日を上限に失効させた。工事期間内の退職・異動は協力会社から通知を受け、担当PMが即日無効化する。延長は理由と新期限の承認を必須とし、月次棚卸しで通知漏れを補完した。自動期限だけでは途中離脱者を発見できないため、通知と定期確認を組み合わせた。 第三の設計柱は、BIMデータのダウンロード制御とDLP設定である。Autodesk Construction Cloudの「ファイル設定」でダウンロード権限を限定し、協力会社ロールはビューア参照のみで図面本体をダウンロードできない設定にした。プロジェクト終了後のデータアーカイブには、Azure Storageの不変ストレージ（WORM設定）を採用し、改ざん防止と証拠保全を兼ねた保管を実現した。 第四の柱はオフライン端末の保護である。端末はIntuneへ登録し、暗号化と自動ロック、本人認証、キャッシュの保存期限を強制する。紛失時はアクセス資格を失効させ、再接続時のワイプを指示する。通信が切れている間は遠隔消去できないため、暗号化と鍵保護を主な防御とし、保存できるデータを業務上必要な範囲に絞った。 推進においての課題は、協力会社に対するID管理の説明と同意取得である。中小の設計事務所は自社IDプロビジョニングのIT体制が弱く、Azure AD B2Bの登録手順に戸惑う事例が続出した。私は協力会社向けのオンボーディング手順書（PDF・動画）を整備し、IT担当者が不在の事務所向けに電話サポート窓口を設けることで解消した。
結論（設問ウ）
移行後6か月、工事終了日の自動失効が新管理対象で機能した。一方、移行前に発行した旧アカウントが残り、竣工後30日を超える残存件数は従来比89%減にとどまった。旧アカウントも同じ台帳へ移し、権限の要否を個別に確認する。 紛失端末2台には再接続時のワイプを行ったが、消去成功だけで紛失前の漏洩がないとは断定せず、暗号化状態とアクセスログも確認した。今後はアクセスログの取得範囲と保持期間を標準化し、連携に不足があるサービスは補助記録と定期確認で補う。
試験制度・公式過去問の確認: IPA 情報処理技術者試験
医療・ヘルスケアの参考答案例
約 1,596 字序論（設問ア）
私はI大学病院（病床数1,200床、職員数3,500名）の医療情報部でセキュリティを担当している。I病院は地域の中核病院として救急・高度医療を担い、電子カルテ・PACS（医療画像）・手術支援システムなど100以上の医療情報システムを運用している。厚生労働省の「医療情報システムの安全管理に関するガイドライン第6.0版」（2023年5月）への対応が急務となっている。 2023年度、I病院では医療情報のクラウド化方針が経営層で承認された。電子カルテの診療データを国内医療クラウドへ移行し、オンライン診療・他施設連携・AI診断支援への基盤整備を目的とする。私はクラウドセキュリティ設計を担当した。 移行時の課題は、患者情報の機密性・完全性を保ちつつ、診療を止めないことだった。クラウド提供者との責任分界が曖昧では、障害時の連絡や復旧が遅れる。外部連携先への権限、医療機器との通信、ログの保管と閲覧責任も移行前に定める必要があった。
本論（設問イ）
私は医療情報部、診療部門、クラウド提供者と協議し、以下の設計を策定した。 第一の設計柱は、医療専用クラウドサービスの選定基準の策定である。クラウドサービス選定にあたり、「ISMAP（政府情報システムのためのセキュリティ評価制度）またはISO 27001認証取得済み」「データ保存先が日本国内に限定」「技術的安全管理措置として保存データのAES-256暗号化・通信TLS1.2以上」「緊急時のデータ復元保証（RTO 4時間・RPO 1時間）」の四要件を満たすサービスのみを選定対象とした。この基準はガイドライン6.0版のリスク対策要件とマッピングして文書化した。 第二の設計柱は、医療情報の分類別アクセス制御の設計である。電子カルテデータを「診療情報（要保護）」「請求データ（準要保護）」「匿名統計データ（一般）」の三段階に分類し、それぞれのアクセス権限を医師・看護師・事務職員・外部連携機関別に設計した。クラウド上の電子カルテAPIへのアクセスは、院内の認証基盤（Active Directory）からSAML認証経由でシングルサインオンする設計とし、クラウドサービスに直接ローカルアカウントを作成しない設計とした。 第三の柱はネットワーク分離である。医療機器のVLAN-A、カルテ端末のVLAN-B、外部連携のVLAN-Cを分けた。通常のカルテ閲覧はBから許可し、Cは認証した連携ゲートウェイから必要なAPIだけを利用する。Aとカルテ間の検査結果連携は専用ゲートウェイで必要な宛先と通信のみ許可し、一般端末から医療機器への直接接続を拒否した。 第四の柱はログの保全である。ログごとの利用目的と調査に必要な期間をリスク評価し、当院ではカルテアクセス履歴を5年保存すると定めた。一律の法定保存年限とは扱わない。暗号化と変更・削除制限を設け、記録管理と閲覧承認を分離した。定期的に抽出して読めることを確認し、設定変更も監査対象とする。 現場は認証操作の増加を懸念した。職員証の証明書と本人だけが知るPINによる認証を基本にし、スマートフォン方式ではパスワードと認証アプリを組み合わせた。カードをかざすだけの操作をMFAとは扱わない。セッションを短時間で安全に切り替える方式を病棟で試し、共用IDを使わずに交代勤務へ対応した。
結論（設問ウ）
移行後6か月、カルテへの認証と患者情報への権限を分けて管理でき、医療機器への直接到達を制限できた。試験では許可した診療・検査連携が継続でき、権限外の参照は拒否された。これらは確認した機能の結果であり、ガイドライン全項目への適合を意味しない。 残る課題はクラウドAPIの変更に設定が追いつかないことである。次期は構成管理と自動試験を整え、仕様変更時に認証・認可・外部連携を再検証する。提供者の変更通知と当院の影響判断を結び付け、未検証のまま診療へ影響する変更を適用しない。
試験制度・公式過去問の確認: IPA 情報処理技術者試験
公共・自治体の参考答案例
約 1,478 字序論（設問ア）
私はJ市（人口約280万人）の情報政策課に在籍し、ガバメントクラウド移行に伴う情報セキュリティ設計を担当している。デジタル庁のガバメントクラウド方針のもと、J市では住民サービス基盤（税・福祉・住民票）の標準準拠システムへの移行と、それに伴うクラウド環境へのデータ移行が2025年度に予定されている。 政府・自治体が取り扱う個人情報・特定個人情報（マイナンバー）は、「政府情報システムのためのセキュリティ評価制度（ISMAP）」と「マイナンバー法」「個人情報保護法（官民一元化後）」の三重の規制に対応した厳格なセキュリティ設計が求められる。本稿では、J市のガバメントクラウド移行におけるセキュリティ設計について述べる。 移行時の課題は、選定した国内クラウドサービスでも利用者側の設定と運用責任が残ることだった。ISMAPの登録範囲、利用機能、責任分界を確認し、登録だけで自組織の安全性が保証されるとは扱わない。職員の認証、個人情報への権限、オンプレミスとの接続を一体で設計する必要があった。
本論（設問イ）
私はJ市の主任情報セキュリティ管理者として、以下の設計を主導した。 第一の柱は責任分界台帳である。利用するAWS国内リージョンについて、物理基盤など提供者の範囲と、当方が選択・設定・運用するOS、アプリ、権限、データ保護をサービス別に整理した。IaaSとマネージドサービスでは範囲が異なるため、同じ台帳を無条件に流用せず、契約と仕様を確認した。四半期ごとに変更と未対応項目を監査した。 第二の柱は事務単位のデータ認可である。職員IDと業務ロールを対応させ、アプリとDBで担当事務の範囲を制限した。クラウド管理のIAM権限はシステム運用者向けに別管理し、一般職員へDB全体を操作する権限を与えない。個人情報へのアクセス履歴とクラウド管理操作をそれぞれ記録し、業務上不要な権限付与や大量取得を検知する。 第三の柱は職員認証である。庁内ADを認証基盤と連携し、必要なアプリへシングルサインオンする。MFAにはICカードの証明書とPINを用い、人事異動・退職と権限の更新を連動させた。カードを読み取るだけの認証では第二要素がないため、その方式をMFAとは呼ばない。 第四の柱は既存システムとの通信保護である。国内リージョンとの専用線に加え、経路ごとに必要な暗号化を施した。専用線自体が全ての通信を暗号化するわけではない。接続先とポートを許可リストで管理し、移行期間の暫定経路には終了期限を設けた。 推進においての最大の課題は、職員向けの操作教育とITリテラシーの格差への対応であった。私は部署ごとに2時間の移行説明会を11回実施し、新認証フロー（ICカード＋画面操作）の実機演習を取り入れた。ヘルプデスクにはクラウド移行専門の対応窓口を設け、運用開始後30日間は拡充した体制で対応した。
結論（設問ウ）
ガバメントクラウドへの住民基本台帳システム移行後3か月で、不正アクセスインシデントはゼロであった。デジタル庁による点検でも、ISMAPの制御基準への適合が確認された。特にIAM設計の細粒度が評価され、他県への横展開の参考事例として取り上げられた。 課題として、ガバメントクラウドのサービスアップデートへの追従速度が遅く、推奨セキュリティ設定が変更された際の迅速な反映体制の整備が必要である。また、住民サービス向けAPIを外部の福祉システム事業者に開放する次フェーズでは、APIゲートウェイのセキュリティ設計（認証・レート制限・ログ保全）が新たな課題となる。継続的なセキュリティ強化で住民の信頼に応えていく。
試験制度・公式過去問の確認: IPA 情報処理技術者試験
製造業の参考答案例
約 1,211 字序論（設問ア）
私はM電機（売上高4,800億円、従業員4,200名、国内6工場・海外3工場）のクラウド移行でセキュリティ設計を担当した。生産管理MES、製品情報PLM、CAD/CAEの基盤をAWS主体、Azure副系へ段階移行する計画である。生産データを拠点間で共有し、変動する解析計算の負荷に対応することが目的だった。 課題は、顧客やプロジェクトをまたぐ設計データの漏洩、海外拠点からの管理者権限の濫用、設定誤りによる公開である。クラウド事業者が物理設備を管理しても、利用者の権限とデータ分類は当社の責任として残る。生産設備の停止を避けながら、必要な設計情報だけを必要な担当者へ提供する構成が求められた。
本論（設問イ）
私はまず、利用するサービスごとに事業者と当社の責任を整理した。IaaSのOS更新は当社、マネージドDBの基盤更新は提供者というように分け、設定、暗号化、復旧試験、監査記録の担当と期限を台帳化した。 設計データの機密度とプロジェクトに応じてAWSアカウントとVPCを分け、組織のSCPとIAMで不要な操作やクロスアカウント接続を拒否した。これは論理的な分離であり、アカウントを分けるだけで物理設備が専有されるわけではない。PLMや解析ジョブ内のデータ認可も別に設計し、他案件の入力データや計算結果を指定する否定試験を行った。 保存データは暗号化し、鍵の利用権限とデータ管理権限を分離した。鍵の無効化で業務が止まるため、変更は承認制とし、復旧用データを読む鍵も含めて復元を試験した。GPU解析はジョブごとに作業領域を分け、終了後の一時領域の削除を確認する。 工場との接続は専用経路と暗号化を組み合わせ、管理端末を限定した。接続元IPと端末証明書は接続条件であり、それだけを三要素認証とは数えない。利用者は本人用認証器とPIN等で認証し、管理操作は短時間の昇格を承認して記録する。 設定はIaCで変更履歴を管理し、公開設定や広すぎる権限を検査した。CloudTrailや設定監視のログは運用環境から分離した保管先へ送り、停止・削除の試みも検知する。海外拠点には通信遅延と旧ツールの互換性の問題があったため、地域別に小さく移行し、業務試験を通過した拠点から展開した。例外設定には責任者と失効日を付け、生産継続を理由とする恒久的な広権限を避けた。
結論（設問ウ）
移行後6か月、権限外プロジェクトへの接続試験は全て拒否され、設定監視の未対応項目も減少した。GPU基盤では複数案件を同時実行しながら結果の参照範囲を分けられ、設計部門の待ち時間を短縮できた。クラウド設定のスコア改善だけを情報漏洩防止の証明とはせず、アプリとDBの認可試験も継続した。 残る課題は、設計データを外部AIへ入力する経路と、工場の例外接続である。次期は承認済みのAI利用経路を整え、入力可能な情報と保存先を審査する。工場ごとの例外は更新計画と合わせて月次で確認し、不要となった経路を確実に閉じる。
試験制度・公式過去問の確認: IPA 情報処理技術者試験
流通・小売業の参考答案例
約 1,188 字序論（設問ア）
私はR流通（売上高8,200億円、従業員12,500名、約340店）のEC・CRM基盤のクラウド移行でセキュリティを設計した。会員は約560万人で、ECの年間流通額は約820億円である。大型セール時には通常の40倍の負荷があり、Google Cloudを中核とした段階移行を計画した。 課題は、拡張性を確保しながら会員情報と決済情報を保護し、分析用途へのデータ提供範囲を制限することだった。クラウド事業者が基盤を管理しても、当社が設定した公開バケットや過大な権限の責任は移らない。需要予測用の分析基盤が会員全員の明細を無制限に抽出できる状態を改める必要があった。
本論（設問イ）
私はEC、CRM、分析、決済関連の各サービスについて責任分界を整理し、アクセス設定、暗号化、バックアップ、障害連絡の担当を定めた。決済は代行業者のトークン化を用い、カード番号を当社の一般業務DBへ持たせない。監査範囲が縮小しても当社の適用要件が全てなくなるわけではないため、決済連携と委託先管理を別に確認した。 Google Cloudでは環境と用途ごとにプロジェクトを分け、サービスアカウントへ必要な権限だけを付与した。人の管理者権限は期限付き承認とし、長期固定鍵を配布しない。Web入口にはWAFとレート制限を設け、負荷試験でアプリやDB側の上限も確認した。 会員情報は利用目的別に提供した。マーケティング担当者には集計済みデータを渡し、明細が必要な処理は承認された実行基盤に限定する。k匿名化や集計を行っただけで法令上の匿名加工情報になったとは判断せず、再識別の可能性、加工基準、提供条件を担当部署が確認する。十分に加工できないデータは個人情報として管理し、自由な持出しを認めない。 保存データとバックアップを暗号化し、鍵管理者と分析担当者を分けた。取得、抽出、権限変更を記録し、大量ダウンロードや公開設定の変更を通知する。漏洩等の疑いは担当部署へ直ちに連絡し、国内の報告対象と期限を確認する手順とした。海外制度の72時間という数字を国内全件の期限として転用しない。 分析部門からは、集計だけではモデル検証ができないとの反対があった。私は承認済みの隔離分析環境を設け、出力を検査してから持ち出す方式を試した。必要な分析を維持しながら、会員明細を担当者のPCへ配布しない運用で合意した。
結論（設問ウ）
移行後のセールでは秒間1,800件の決済を処理し、決済成功率99.97%を維持した。権限外の会員データ抽出や公開設定の試験では拒否・通知が機能した。分析環境の整備により、明細を個人PCへ配布する従来の運用も廃止できた。 残る課題は、顧客対応の会話履歴を外部AIへ送る可能性である。入力内容の分類と承認済み経路を整え、データ保存と再利用条件を確認する。また、新機能の追加で権限が広がらないよう、設計レビューと否定試験をリリース条件へ組み込む。
試験制度・公式過去問の確認: IPA 情報処理技術者試験
通信業の参考答案例
約 1,187 字序論（設問ア）
私はT通信（売上高7,800億円、従業員9,200名、約820万回線）のマネージドサービス、運用支援OSS、課金BSSのクラウド移行を担当した。AWS主体、一部Oracle Cloudを用いて、顧客のクラウド利用拡大と分散した設備の運用へ対応する計画だった。 保有情報には通信の秘密に該当する通信履歴と、契約・課金に関する個人情報等がある。これらを一律に同じ分類へ押し込まず、利用目的と取扱担当者を分ける必要があった。また、基盤の管理を提供者へ委ねても、当社の権限設定、ログの取得範囲、委託先の取扱い確認は残る。移行中のオンプレミスとの接続を含めた設計が課題となった。
本論（設問イ）
私はサービスごとに責任共有の台帳を作成した。IaaSのOS更新、マネージドサービスの設定、データ保護、障害時の連絡を当社と提供者のどちらが担うかを整理した。データ保存先だけでなく、保守アクセスや再委託先の取扱範囲も契約と仕様で確認した。 顧客と機密度に応じてAWSアカウントやVPCを分け、IAMとネットワーク制御で不要な横断接続を拒否した。専用アカウントは論理分離であり、物理的に専有された設備ではない。OSS・BSSのアプリとDBでも担当顧客の認可を行い、アカウントの分割だけで全データの分離が完了したとはしなかった。 管理者はMFAを使い、PAM経由でチケットに対応した対象設備へ限定接続する。期限付きの権限付与と操作記録を組み合わせ、緊急時も承認者、対象、解除期限を残した。通信断に備えた代替手順は通常経路と権限を分け、訓練で復旧時間を確認する。 データは保存時と通信時に暗号化し、鍵の利用権限を分離した。特に通信履歴を監視基盤へ送る場合は、必要な項目と利用根拠を確認し、一般的な管理ログと区別する。過剰な収集を避け、保存期間、閲覧承認、削除を定めた。通信の秘密を扱う部署を分けるだけで利用が適法になるとは扱わない。 AWSとOracle Cloudで設定検査やログ形式が異なることが困難だった。私は共通の必須項目を定義した上で、各提供者の設定へ対応付けるチェックを作った。移行単位ごとに公開設定、権限外照会、鍵の無効化と復旧を試験し、未確認の項目は台帳に残して責任者の承認を得た。監視の点数だけで移行完了を判定しないことを運用部門と合意した。
結論（設問ウ）
移行後6か月、設定検査と操作ログの確認を両クラウドで実施できた。法人サービスの可用性は99.92%から99.98%へ改善したが、設備更新の効果も含むため、全てをセキュリティ設計の成果とはしなかった。権限外の照会試験と復元試験を定期的に繰り返すことを運用へ引き継いだ。 残る課題は、障害分析に外部AIを使う際の機密情報の扱いである。承認した入力範囲と利用経路を定め、送信内容を記録する。また、暗号資産を棚卸しし、将来の移行では提供者と接続先の対応、性能と互換性を確認する。
試験制度・公式過去問の確認: IPA 情報処理技術者試験