ケイパビリティ
私たちは、システムを設計し実装する過程でセキュリティを組み込みます。信頼境界、アイデンティティ、データ保護、安全なデリバリー、検知がその対象です。これはエンジニアリングの実務であり、ソフトウェアとインフラを設計するのと同じメンバーが担います。
セキュリティは、システムがどう構築されているかに由来する特性です。信頼境界をどこに引くか、アイデンティティをどう確立して伝播させるか、どのコンポーネントがどのデータに到達できるか、そして攻撃者がどれか一つの部分を侵害したときに何を得るか、といった点に表れます。ツールやレビューは欠陥の発見に役立ちますが、アーキテクチャに最初から存在しなかった境界を後から付け加えることはできません。
私たちはサイバーセキュリティを、ライフサイクル全体を貫くエンジニアリングの専門領域として扱います。要件にはデータ分類と悪用ケースを含めます。設計は脅威モデリングにかけます。コードは安全なデフォルトに沿って書き、自動でチェックします。インフラは最小権限とセグメント化されたネットワークで定義します。本番では脅威モデルが予測した振る舞いを監視し、インシデント対応は必要になる前に計画しておきます。
当社が対象とするのは、私たちが設計・構築するシステムのセキュリティと、組織のコンプライアンスプログラムを支えるエンジニアリングです。ISO 27001、SOC 2、PCI DSSといったフレームワークへの対応を支援できるよう、管理策と証跡の収集を設計します。正式な認証とアテステーションは認定を受けた監査人が実施するものであり、独立した第三者によるペネトレーションテストは、当社のエンジニアリング作業へのインプットとしてデリバリー計画に組み込みます。
エンジニアリング領域
セキュアなSDLCでは、デリバリーの各段階にセキュリティ活動を割り当て、最も低コストで修正できる場所で欠陥を見つけます。セキュリティ要件を機能要件とあわせて定義し、設計時に脅威をモデル化し、パイプラインで解析を自動化し、リリース前に検証します。各活動は、レビュー担当者に提示できる記録を残します。
独自開発ソフトウェアへの侵害の大半は、認可、入力処理、セッション管理の欠陥を突くものです。私たちは、エッジで認証を、リソースで認可を行うようにAPIを設計し、すべての入力をスキーマに照らして検証し、アイデンティティごとにレート制限を適用します。OWASP Top 10とOWASP API Security Top 10は、設計そのものではなく、最低限のチェックリストとして使います。
アイデンティティは、現代のシステムにおけるコントロールプレーンです。私たちは、従業員、顧客、ワークロードのそれぞれについて、アイデンティティとアクセス管理（IAM）を設計します。それぞれをどう認証するか、権限をどうモデル化するか、アクセスをどう棚卸しして剥奪するかです。最小権限をデフォルトで適用し、権限昇格は一時的で、承認を経て、ログに記録されるものとします。
クラウドでの侵害は、多くの場合、設定ミスが原因です。公開されたストレージ、広すぎるロール、露出した管理インターフェースなどです。私たちは、組織レベルのガードレール、プライベートネットワーク、デフォルトでの暗号化、継続的なポスチャーチェックによってこれらを防ぎます。コンテナは最小限のイメージからビルドし、root以外で実行し、アドミッションポリシーとネットワークポリシーで制約します。
認証情報とサードパーティのコードは、攻撃者が最も頻繁に再利用する2つの資産です。シークレットはマネージドストアに保管し、実行時に注入し、自動でローテーションします。あわせて、ソース管理にコミットされたものを検出します。脆弱性は管理されたバックログとして扱います。継続的に発見し、悪用可能性と露出度で優先順位を付け、合意した期限に沿って修正します。
予防はいずれ破られます。そのためシステムは、何が起きたかを記録し、重要な場面でアラートを上げなければなりません。私たちは、誰がどのリソースに何をしたかを捉える監査ログを設計し、改ざん耐性のあるストレージに送り、脅威モデルをもとに検知ルールを構築します。インシデント対応は、役割、ランブック、連絡経路、訓練を含めて事前に準備します。
セキュリティは、開発が終わった後でアプリケーションに後付けできるものではありません。フラットな一つのネットワーク、一つのデータベースユーザー、「認証済みの呼び出し元」という一つの暗黙の概念で設計されたシステムは、周囲にスキャナーやファイアウォールをいくつ配置しても、その性質を持ち続けます。その段階で意味のある是正は構造的なものになりますが、プロジェクト終盤での構造変更は高くつき、たいていは先送りされます。
システムのセキュリティ態勢の大部分は、4つの設計判断で決まります。信頼境界は、データがある信頼レベルから別の信頼レベルへ移る場所、つまり検証と認証を行わなければならない場所を定めます。アイデンティティは、すべてのユーザーとワークロードが自らをどう証明し、その証明が呼び出しの連鎖の中をどう伝わるかを定めます。データ分類は、どのデータに暗号化、マスキング、アクセス制限、データレジデンシーの管理が必要かを定めます。影響範囲（ブラストラディウス）は、攻撃者が一つのコンポーネントを侵害した後に何に到達できるかを定めます。
これらを早い段階で正しく決めておけば、後の管理策はシンプルで局所的なものになります。スコープを狭く絞った認証情報しか持たないサービスは、そもそも読み取れなかったデータベースを漏えいさせることはできません。データ層で強制されるテナント識別子は、一つのハンドラーでチェックが抜けていても迂回できません。私たちはこれらを、可用性やレイテンシと同じ重みを持つアーキテクチャ要件として扱います。
アーキテクチャ
アイデンティティ
すべてのリクエストを認証・認可する
エッジ
アプリケーション
データ
インフラ
検知・対応
統制は破られる前提で備える
脅威モデリングは、設計について4つの問いに答えます。何を作っているのか、何が問題になり得るのか、それにどう対処するのか、そしてその対処は十分だったのか、です。プロセス、データストア、外部アクター、それらの間の信頼境界を示すデータフロー図を出発点とし、各要素を、なりすまし、改ざん、否認、情報漏えい、サービス拒否、権限昇格の観点で検討します。
成果物は、優先順位を付けた脅威の一覧と、それぞれに対する判断です。軽減する、受容する、移転する、あるいは設計を変えて排除するかを決めます。軽減策はバックログ項目とテストケースになり、残った脅威は本番の監視で何を検知すべきかの指針になります。脅威モデルは、新しい連携先、データストア、外部から到達可能なインターフェースが加わるなど、アーキテクチャが変わるときに見直します。
この取り組みは、セキュリティの専門家がファシリテーターを務め、エンジニア自身が設計中に行うときに最も価値を発揮します。新機能についての1時間のセッションが、認可モデルを変えたり、不要なデータフローをなくしたりすることは珍しくありません。その時点であれば、変更のコストは図の修正だけで済みます。
ゼロトラストは、ネットワークの内側にあるものは安全だという前提を、すべてのリクエストを発信元にかかわらず認証、認可、暗号化するという要件に置き換えます。ネットワーク上の位置は、もはや認証情報としては扱われません。アクセスの判断は、呼び出し元のアイデンティティ、デバイスやワークロードの状態、リソースの機密度をもとに、リクエストごとに行います。
アプリケーションアーキテクチャでは、これは次のことを意味します。SPIFFEのようなフレームワークが発行するワークロードアイデンティティを用いたサービス間の相互TLS、各サービスで評価する認可ポリシー、そして上流のヘッダーを信頼するのではなく署名付きトークンで伝播させるユーザーコンテキストです。従業員のアクセスについては、フラットなVPNの代わりに、社内ツールの前段にアイデンティティ認識型プロキシを置くことを意味します。導入は段階的に進めます。最も機密性の高いデータ経路から始め、強固なアイデンティティを確立し、可視性が高まるにつれてポリシーを厳格化していきます。
ISO 27001、SOC 2、PCI DSSといったフレームワークは、管理目的を記述しています。アクセスが制限されていること、変更が承認されていること、データが保護されていること、イベントが記録されていること、インシデントが処理されていることです。その大半は、エンジニアリングの仕組みに直接対応します。必須レビューを伴うInfrastructure as Codeは変更管理の証跡になります。アクセスの棚卸しを伴う一元的なアイデンティティ管理はアクセス管理の証跡になります。イミュータブルな監査ログは監視の証跡になります。
私たちは、こうした証跡が通常運用の副産物として、パイプライン、クラウドAPI、アイデンティティプロバイダーから自動的に収集されるようにシステムを設計します。これにより監査のコストが下がり、さらに有益なこととして、管理策が審査の前に寄せ集められるのではなく、継続的に機能している状態になります。システムはこれらのフレームワークへの対応を支援するよう設計されますが、審査と認証は認定を受けた第三者の役割です。
エンジニアリングの進め方
セキュリティの作業はリスクに応じて順序付けます。守るべきものを把握し、構造を正し、チェックを自動化し、そのうえで障害に備えます。
システム、データストア、データフローを棚卸しし、機密度と規制上の義務に基づいてデータを分類します。これにより、管理策が何を守るのか、どれだけの強度が必要かが定まります。
信頼境界を引き、設計に対する脅威をモデル化し、アイデンティティ、ネットワークセグメンテーション、暗号化、テナンシーのモデルを決定します。成果物は、個々の脅威までたどれる一連のセキュリティ要件です。
認証、認可、入力検証、シークレットの取り扱い、監査ログを、テスト済みの共有コンポーネントとして実装します。クラウドのガードレールと最小権限のロールは、インフラコードとして記述します。
静的解析、依存関係とコンテナのスキャン、シークレット検出、ポリシーチェックを、ブロックの基準として合意したしきい値とともに、すべての変更に対して実行します。脅威モデルから導いたセキュリティテストケースは、機能テストと並行して実行します。
独立した第三者によるペネトレーションテストを、安定したビルドを対象に、脅威モデルを踏まえたスコープで計画します。検出事項はほかの欠陥と同じバックログに入り、重大度に応じた修正期限と再テストの対象になります。
監査ログとセキュリティテレメトリーを検知ルールとダッシュボードに取り込み、インシデントランブックを訓練で検証します。インシデントやヒヤリハットのたびに、個人を責めない振り返りを行い、設計、コード、プロセスの具体的な変更につなげます。
トレードオフ
アーキテクチャを確定する前に、お客様のチームとともに検討する問いです。
本番対応
すべてのリクエストを認証し、認可はリソースで強制し、認証情報は短命で単一の目的に限定します。データは転送中も保存時も暗号化し、管理者アクセスはジャストインタイムで付与して記録し、ネットワーク経路と権限にはデフォルト拒否を適用します。
セキュリティ管理策は、システムとともにスケールするように設計します。トークン検証はステートレスにし、ポリシーの判断結果は短い有効期間でキャッシュし、レート制限は分散させます。共有ライブラリとプラットフォームレベルのガードレールにより、サービスを追加するたびにセキュリティを実装し直す必要がなくなります。
監査ログは、セキュリティに関わるすべてのイベントについて、実行者、操作、リソース、結果、発信元を記録し、ログを生成したシステムからは変更できない場所に保管します。脅威モデルから導いた検知ルールが、異常な認証、権限の変更、データアクセスのパターン、ポリシー違反に対してアラートを上げます。
変更はリリース前に自動セキュリティチェックとポリシーゲートを通過し、アーティファクトは署名されてアドミッション時に検証され、インフラの権限はレビューを経たコードによってのみ変更されます。緊急パッチも同じパイプラインを優先経路で通すため、速度を優先しても検証が省かれることはありません。
システムは、OIDCとSAMLで社内のアイデンティティプロバイダーとフェデレーションし、ログを組織のSIEMに転送し、ガバナンスとコンプライアンスのツールに証跡を提供します。サードパーティやパートナーとの連携は、個別に認証し、スコープを狭く絞り、信頼できない入力として監視します。
ワークロードとお客様の既存環境に合わせて選定します。
ゼロから本番へ
アイデア
ディスカバリー
システムアーキテクチャ
UX・プロダクトデザイン
アプリケーション開発
AI・データレイヤー
クラウドインフラ
セキュリティ
QA・パフォーマンス
デプロイ
オブザーバビリティ
継続的な進化
FAQ
いいえ。当社はエンジニアリング企業です。ISO 27001、SOC 2、PCI DSSといったフレームワークが求める管理策と証跡を備えたシステムを設計・構築し、組織が任命する認定監査人や審査員と協力して作業します。認証とアテステーションの判断は、それらの機関が行うものです。
私たちは、ペネトレーションテストをデリバリーに組み込みます。脅威モデルに基づくスコープの定義、環境の準備、検出事項のトリアージ、修正の実装です。独立性を確保するため、テスト自体は、システムを構築したチームとは別の専門会社が実施するのが最善であり、私たちは組織が選定したテスト実施者と連携します。
アーキテクチャの段階です。信頼境界、アイデンティティ、テナンシー、データ配置など、セキュリティへの影響が最も大きい判断はこの時点で下され、後から覆すには大きなコストがかかります。後の段階からの関与にも意味はありますが、選択肢は補完的な管理策に限られていきます。
はい。まずアーキテクチャと脅威のレビューを行って構造的なリスクを見つけ、悪用可能性と影響度に応じて是正の順序を決めます。初期の典型的な作業は、認証情報とシークレットの管理の適正化、認可の抜け、ネットワーク上の露出、監査ログの欠落への対処であり、その後にアイデンティティとセグメンテーションのより踏み込んだ変更が続きます。
モデルの入力と出力を、信頼できないものとして扱います。モデルが到達できるツールとデータを制限し、認可はモデルの外側で強制し、出力はアクションを引き起こす前にフィルタリングして検証し、やり取りをレビューのために記録します。プロンプトインジェクションは、フィルタリングで確実に取り除くことができないため、封じ込めるべきアーキテクチャ上のリスクとして扱います。
