お役立ちコラム
セキュリティアーキテクトの仕事内容と必要なスキル
はじめに
セキュリティアーキテクトは、システムを作る前の段階から「どこが危ないか」「どう守るか」を決め、設計に落とし込む仕事です。後から直すより、最初に決めておくほうが手戻りが減り、費用や時間のムダも抑えられます。
この記事では、セキュリティアーキテクトの仕事内容を、上流工程の流れに沿って整理します。そのうえで、現場で求められるスキルを「技術」「設計」「ビジネスと統治」に分け、何を身につければよいかを具体的に解説します。
セキュリティアーキテクトの役割と仕事内容
セキュリティアーキテクトの定義と立ち位置
セキュリティアーキテクトは、開発者や運用担当が動きやすいように、守りの設計図とルールを用意する役割です。現場では「設計」「標準」「方針」「手順」を整え、組織のセキュリティポリシーとズレないように保ちます。
ニューヨーク市道路交通局(DOT)の採用情報は、セキュリティアーキテクトの職務として、セキュリティの設計・計画・標準・方針・手順を、市全体の方針や組織の計画と整合させること、方針や標準や設定の標準運用手順を定義して維持すること、業界動向の監視やベンダー連携、遵守の確保、改善提案、潜在的な露出や設計上の欠陥の特定と是正まで含むと整理しています(参照*1)。
ここで押さえたいのは、セキュリティアーキテクトが「実装だけをする人」ではない点です。複数の関係者の間に立ち、決めるべきことを決め、例外や判断基準も含めて線引きを作る立ち位置になります。
上流工程で担う設計業務と意思決定
上流工程では、要件定義や基本設計の段階で、守る対象と守り方を決めます。たとえば、個人情報を扱うなら暗号化の範囲、管理画面なら強い本人確認(認証)とアクセス制御、外部連携があるなら接続の許可条件やID管理の方式などを、最初に決めて設計に入れます。
米国のCMSは、System and Services Acquisition(システムやサービスの取得・開発・維持の流れ)に、情報セキュリティとプライバシー要件を組み込む考え方を示しています。CMSは、早い段階で資源を配分してライフサイクル全体で管理すると、リスクや再作業を抑え、関係者のプロジェクト達成を加速できると説明しています。また、第三者提供者に厳格な要件を設け、文書化、構成管理、供給網の保護を徹底すると述べています(参照*2)。
意思決定の場面では、理想だけでなく現実も見ます。期限や予算がある中で、どの対策を必須にし、どれを段階的に入れるかを決める必要があります。そのために、影響が大きい事故のパターンを先に潰す、外部委託や購入サービスの条件を契約前に固める、といった判断が仕事の中心になります。
成果物と関係者コミュニケーション
セキュリティアーキテクトの成果物は、設計書だけではありません。方針、標準、例外の扱い、レビューの観点、運用で守る手順など、チームが迷わないための材料をそろえます。成果物が弱いと、開発のたびに解釈が割れ、同じ議論が繰り返されます。
香港政府のGovCERT.HKは、情報資産の機密性・完全性・可用性を守るために、システム開発ライフサイクルの全段階へセキュリティ対策を組み込み、事前にリスクを特定して軽減する目的を示しています。さらに、4つの主要フェーズにセキュリティ活動を結びつけ、フェーズ間の制御ゲートで進行を評価して決定すると整理しています(参照*3)。
関係者とのコミュニケーションでは、難しい言葉を減らし、判断材料をそろえることがポイントです。開発者には実装に落ちる形で、経営層にはリスクと費用の関係が見える形で、監査や法務には証跡が残る形で説明し、制御ゲートの場で合意を作っていきます。
求められるスキルセット
技術スキル
技術スキルは、細かい実装を全部自分で書けることよりも、危ない作りになっていないかを見抜き、直し方を示せることが中心です。特に、外部とつながる部分、権限の扱い、ログの残し方、暗号化の使いどころは、設計で差が出ます。
API(アプリ同士をつなぐ窓口)の守り方は典型例です。Curityは、APIは必ずゲートウェイの背後に置くと述べています。APIゲートウェイは、通信の共通機能を集約し、すべてのリクエストに対して、回数制限、不正な利用者の遮断、適切な記録といったセキュリティ機能を適用でき、さらに経路やヘッダーの書き換え、業務の指標の収集といった実務面にも役立つと説明しています(参照*4)。
また、ウェブアプリの安全性を確認する観点も欠かせません。OWASP(ウェブの安全を良くする国際的な非営利団体)のASVSは、ウェブアプリの技術的なセキュリティ対策を検証する基準であり、安全な開発の要件リストも提供すると整理しています。ASVSは、商用のオープン標準を使って、検証のカバー範囲と厳密さを市場で標準化することを目的にしており、Downloadsページで5.0.0を示しています(参照*5)。
運用につながる技術としては、ログ管理と監視も外せません。設計段階で「何のログを、どこに集め、どれくらい保管するか」を決めておくと、SIEM(ログを集めて相関分析する仕組み)や監視ツールの設定がブレにくくなり、インシデント対応の初動も速くなります。
技術スキルを伸ばすときは、暗記よりも、設計の判断に使える形にするのが近道です。たとえば、ログは何を残せば調査できるのか、暗号化はどこまでやれば漏えい時の被害を減らせるのか、といった問いに、理由つきで答えられる状態を目指します。
設計スキル
設計スキルは、守りを「ルール」から「設計図」に変換する力です。要件を文章で書くだけでは、開発の現場で解釈が割れます。画面、データ、通信、運用の流れに落として、誰が見ても同じ動きになるように決めます。
クラウドセキュリティアライアンス(クラウドの安全の標準化を進める国際団体)は、Cloud Controls Matrix(CCM)を、クラウドセキュリティの統治の枠組みとして整理し、197のコントロール目標を17の領域に分けて示しています。さらに、クラウド供給網の各当事者が実装すべきコントロールを示し、責任分担を明確にして実装プロセスの責任性を高めることを目的にすると説明しています(参照*6)。
この種の枠組みを使えると、設計の抜け漏れを減らせます。たとえば、クラウド事業者が守る範囲と、自社が設定で守る範囲を分けて書けるため、事故が起きたときの責任の押し付け合いも減ります。設計レビューでは、197の目標を丸暗記するのではなく、自社のシステムに関係する領域を選び、設計書の項目に落として確認できる形にします。
クラウドでは責任分担の考え方も前提になります。MicrosoftはAzureの説明で、物理データセンターや基盤インフラはMicrosoftが、データ・アプリケーション・アイデンティティ・アクセス管理は利用者が担う、といった共有責任モデルを示しています。IaaS/PaaS/SaaSで分担が変わるため、採用するサービス形態に合わせて、どこを自社の設計責任として書くかをはっきりさせます(参照*7)。
設計スキルの実務では、図と表が武器になります。データの流れ図で個人情報が通る場所を示し、権限表で誰が何をできるかを固定し、例外が出たときの判断基準も書きます。こうした形にすると、開発者は実装しやすく、運用担当は守りやすくなります。
ビジネススキルとガバナンス
ビジネススキルは、セキュリティを事業の動きに合わせて回す力です。ガバナンスは、ルールを作って終わりではなく、守れているかを確認し、変化に合わせて更新する仕組みです。ここが弱いと、良い設計をしても現場で形だけになりがちです。
IPA(情報処理推進機構)は、ITSS+(プラス)のセキュリティ領域で、セキュリティ関連業務を17分野に整理し、各分野に求められる知識・技能の概要をまとめ、体制構築や人材育成・配置で共通言語として活用できるようにしています。また、2022改訂版では、従来の3分割を廃止したことを示し、スキルやタスクの網羅性を機械的に診断するだけでは特定分野の強みに偏るおそれがある点に留意が必要だと述べています(参照*8)。
この注意点は、セキュリティアーキテクトの仕事に直結します。チェック項目を埋めるだけでは、事業の優先順位やシステムの特性に合わない対策に時間を使いがちです。関係者と合意しながら、守る対象、優先順位、例外の扱い、監査の観点を決め、運用で回る形に整えることが、ビジネススキルとガバナンスの中心になります。
あわせて、役割を言語化する枠組みも知っておくと便利です。NISTのNICE Frameworkは、サイバーセキュリティの仕事をTask・Knowledge・Skill(TKS)で整理し、Work Roles(役割)やCompetency Areas(能力領域)を共通言語として扱えるようにしています。Work Rolesは職務名そのものではなく、1つの職務に複数の役割が含まれる場合がある、と説明しています(参照*9)。この見方を使うと、職務経歴書で「やったこと」をタスク単位に分けて示しやすくなり、単価交渉の根拠も作りやすくなります。
上流で活躍するためのロードマップとキャリア戦略
必要経験の積み方と職務の拡張
上流で活躍するには、技術だけでなく、現場と経営の間をつなぐ経験が必要です。まずは、設計レビュー、要件の整理、運用ルール作りなど、意思決定に近い仕事を少しずつ増やします。あわせて、止められない現場(工場や社会インフラなど)で求められる考え方も知ると、リスク評価や優先順位づけがやりやすくなります。
IPAの産業サイバーセキュリティセンターは、経営層と現場担当者をつなぐ人材として「中核人材育成プログラム」を実施し、社会インフラ・産業基盤の対策強化をテーマに、テクノロジー(OT・IT)、マネジメント、ビジネス分野を総合的に学ぶ1年程度のトレーニングだと説明しています。受講者が自社に近い環境で演習できるよう、各業界のシステムを想定した模擬システムも使うと示しています(参照*10)。
このような学び方を参考にすると、職務の拡張がしやすくなります。技術の深掘りに加えて、管理や事業の観点をセットで扱う経験を積むと、上流の会議で合意を取りやすくなります。
ポートフォリオと実績の作り方
ポートフォリオは、作ったものを並べるだけでは弱くなります。上流の仕事では、設計の骨組み、責任分担、非機能要件(性能や可用性など、機能以外の要件)をどう整理したかが伝わる形が有効です。さらに、設計を変えた理由と、運用で守れる形にした工夫も書けると、再現性が見えます。
AWSの資料は、設計の骨組みづくりとして、設計の基本方針、設計書一覧、設計書項目の整理、詳細設計書の取り扱い方針、進捗の定義を挙げ、設計書に非機能要件や目的、責任分掌(RACI)などを含め、将来の設計改訂を見据えたリンクを設けると示しています。また、静的解析としてSAST(ソースコードを実行せずに弱点を探す検査)やLint(書き方の誤りを見つける検査)を挙げ、ツール例にcfn-lint、TFLint、checkov、cdk-nagを示しています(参照*11)。
この内容を踏まえると、実績は「設計書の型」と「検査の仕組み」をセットで示すと強くなります。たとえば、RACIで誰が決めるかを固定し、静的解析の結果を設計レビューの材料にする流れを作った、という形です。加えて、脆弱性診断やペネトレーションテストの結果を、次の設計にどう反映したかまで書けると、DevSecOps(開発の流れにセキュリティ検査を組み込む考え方)として説明しやすくなります。
高単価案件に直結する資格とフレームワーク
高単価案件では、個人の経験談よりも、説明責任を果たせる枠組みや指標が求められます。クラウドでは、構成が自動化され、デプロイ(配布)や運用の安定性と信頼性を支える制御プレーン(管理の仕組み)が前提になりやすいため、従来の「文章で全部説明する」やり方が合わない場面も出ます。
FedRAMP(米国政府のクラウド評価制度)は、現代のクラウドサービスが自動化された構成管理と、デプロイ時・運用時の安定性と信頼性を確保する制御プレーンを用いると説明しています。また、単純なクラウドネイティブサービスでは、必要に応じて自動検証を通じて、従来の制御別の説明を削減できると述べています。改訂履歴として、25.12AはKSI(重要なセキュリティ指標)の明確さと期待値を改善する更新で、いくつかのKSIは撤回されたと示しています(参照*12)。
この方向性に合わせるなら、資格は暗記型よりも、運用で測れる指標や自動検証と相性がよい知識を優先すると説明が通りやすくなります。フレームワークは、CCMのように責任分担を明確にできるもの、ASVSのように検証基準として説明できるものを、案件の性質に合わせて使い分けます。
ここで意識したいのは、フレームワークをそのまま貼り付けないことです。案件の目的に合わせて、どの指標で合否を決めるか、どこまでを自動検証に寄せるかを決め、関係者が同じ言葉で話せる状態を作ります。
おわりに
セキュリティアーキテクトの仕事内容は、上流工程で守りの設計図とルールを作り、関係者の合意を取りながら、開発と運用に落とし込むことです。技術だけでなく、設計としての表現力と、組織で回すためのガバナンスがセットで求められます。
スキルを伸ばすときは、APIやウェブアプリの検証基準、クラウドの責任分担、制御ゲートや指標といった「判断に使える型」を持つと、上流の意思決定に参加しやすくなります。自分の経験を設計書や運用の仕組みとして残し、次の案件でも再現できる形にしていくことが、キャリアの土台になります。
お知らせ
セキュリティアーキテクト 仕事内容 スキル セキュリティアーキテクトの業務範囲や必要スキルを整理し、案件選びやスキル棚卸しの判断材料とし、最新のフリーランス案件情報で実務に直結するスキルを確認しましょう。
インフラエンジニア 仕事内容を把握することは、案件選びやスキル棚卸しに不可欠です。業務範囲や必須スキルを確認し、フリーランス向けの最新案件情報も参考にしましょう。
cyseekではフリーランスのITエンジニア向けの案件をご紹介しています。
案件に関する新着情報は、以下のリンクからご覧いただけます。
参照
- (*1) New York City – Security Architect
- (*2) System and Services Acquisition (SA)
- (*3) https://www.govcert.gov.hk/doc/PG%20for%20Security%20by%20Design_EN.pdf
- (*4) API Security Best Practices
- (*5) https://owasp.org/www-project-application-security-verification-standard/
- (*6) CSA – Cloud Security Alliance Announces Implementation Guidelines v2.0
- (*7) Docs – Introduction to Azure security
- (*8) IPA 独立行政法人 情報処理推進機構 – IPA 独立行政法人 情報処理推進機構
- (*9) NIST – NICE Framework Work Role Videos
- (*10) IPA 独立行政法人 情報処理推進機構 – IPA 独立行政法人 情報処理推進機構
- (*11) https://pages.awscloud.com/rs/112-TZM-766/images/AWS-28_Architecture_AWS_Summit_JP_2024.pdf
- (*12) Key Security Indicators ¶
関連記事
-
なぜセキュリティインシデント対応の仕事が注目されるのか?
はじめに 近年、サイバー攻撃や情報漏えいなどのセキュリティインシデントが増加し、企業や組織は迅速な対応と高度な知見を備える体制を求められています。 インシデント対応は、単なるシステム障害や情報漏えいからの復旧にとどまらず・・・
-
インフラエンジニアとは?仕事内容や必要なスキルなど解説
昨今、求人サイトや転職エージェントで「インフラエンジニア」の求人を目にする機会が多くあります。インフラエンジニアは専門性が高い職種のため、高い需要に対して担い手が不足しています。 今回は、インフラエンジニアの業務と求めら・・・
-
年収から見たセキュリティコンサルタントの魅力とは?キャリアパスや取るべき資格も解説
エンジニアとしての成功は、年収だけで測れるものではありません。仕事のやりがいだったり、理想のワークライフバランスだったり、恵まれた職場環境も重要な要素です。 しかし、年収もまた重要な要素の一つであり、高いに越したことはな・・・
