ここ数年、ネットワークやアプリケーションのアクセスにおける主要なテーマの1つが「ゼロ トラスト」という概念です。このホワイトペーパーでは、ゼロ トラストがその核心において、アクセスだけでなく、より広くサイバーセキュリティ分野全体に適用できるいくつかのシンプルな考え方を特徴としていることを説明します。
このホワイトペーパーでは、ゼロ トラストに関する幅広い概念を包含するフレームワークを提示し、それらの概念を今日のアプリケーション セキュリティのビジネス リーダーを動かしている現在のビジネスの状況と関連付けます。最後に、ゼロ トラストの考え方の体系が持つ特徴、つまり現在と将来の脅威に対処するためのツールとセキュリティの実装の原動力について説明します。これについては、後続のホワイトペーパーで詳しく取り上げる予定です。
このホワイトペーパーの目的は2つあります。1つは、アプリケーション ビジネス リーダーが持つべきセキュリティの考え方を伝えること、もう1つは、今後のホワイトペーパーで説明するセキュリティ担当者のためのフレームワークを紹介することです。
「ゼロ トラスト」という用語は、抽象度の異なるさまざまな概念と関連付けられています。あるときは特定のソリューション アーキテクチャを指し、あるときは特定の技術を適用するための規定を指し、またあるときは製品の特性を指します。私たちは、ゼロ トラスト セキュリティの核心は信念、つまり考え方の一体系であり、そこから技術や戦術が生まれ、特定の技術を活用することで、広範なセキュリティ脅威に対処することができると考えています。
ゼロ トラスト セキュリティ(ZTS)の根底にある考え方の体系は、数年前の「多層防御」から始まったセキュリティの考え方の進化における次のステップと見なすことができます。多層防御は、単一の防護層はわずかではあるが実際に破られる可能性があるが、重要な資産の保護層を増やすことでその可能性を減らし、攻撃者の動きを鈍らせ、攻撃を成功させるために多くのリソースを使わざるを得なくするという考え方に基づいています。
ゼロ トラストは、この考え方を次の3つの点で進化させたものです。
この考え方の進化は、時間と経験の結果であるとも言えますが、他の2つのアプリケーション セキュリティの傾向が重なることで、ますます強められています。特に今日のアプリケーション アーキテクチャは、とりわけアプリケーション インフラストラクチャの「内部」からの脅威に対して、アプリケーションの脆弱性をより大きく開いている可能性があり、これを今日のますます巧妙化する攻撃者が悪用する恐れがあります。しかし幸いなことに、セキュリティ ツール、特に最新のデータ収集・分析機能と組み合わせて使用することで、防御戦略の主要なコンポーネントを実用化することが可能になりました。
この導入的なホワイトペーパーの後半では、ゼロ トラスト セキュリティに対する当社のアプローチのフレームワークとその範囲について概要を説明します。次のセクションでは、問題提起とゼロ トラストへの他の新しいアプローチとの関係について説明し、ソリューション技術とそのアプリケーションの選択の指針となる主要な考え方、つまり「Why(なぜ)」について説明します。今後のホワイトペーパーでは、ゼロトラスト成熟度モデルに関連する認証、アクセス制御、AI支援分析などの特定の技術に課される要件である「How(どのように)」を掘り下げていく予定です。
Simon Sinek氏の「Whyから始めよう」というアプローチは、以下の図1に示すように、ZTSのフレームワークを伝えるのに効果的なツールです。この図は、外側から内側への視点で考えると、ZTSが対応する脅威の種類から始まり、使用するセキュリティ手法へと掘り下げ、最終的にすべてを共通の原則に集約することができます。また、内側から外側への視点で考えると、北極星のように常に同じ方向へと導く核となる考え方から始まり、そこから適切なツールや手法が生まれ、さまざまな脅威に対処できるようになります。
後のセクションでこの図の同心円の各層について掘り下げていきますが、ここで簡単に説明します。
ゼロ トラスト セキュリティは、アプリケーション、インフラストラクチャ、デリバリのすべてのスタックにわたり包括的に拡張し、開発パイプライン全体をカバーするものであるべきです。具体的には、次のものが含まれます。
従来、ゼロ トラストの焦点はアプリケーション開発およびデリバリ チームに向けられ、多くの場合、Dev、DevOps、DevSecOps、およびSREのペルソナとして捉えられてきました。私たちはこれをより大きな視野で捉えます。すなわち、ゼロ トラストへの包括的なアプローチには、理想的には、従来と異なるペルソナやインフラストラクチャ、さらにサプライ チェーンの調達戦略などのワークフローが含まれるべきであるということです。
CIOやCISOにとっての最重要課題の1つは、情報技術をモダナイズし、ビジネスの加速に貢献することです。また、彼らは企業のリスク ガバナンスにおいても重要な役割を担っています。彼らの目標は、ビジネス リスクを最小限に抑えながら、新しいデジタル エクスペリエンスで顧客を満足させ、サードパーティとのデジタル接続によって業務効率を向上させ、従業員がどこにいても生産的に働けるようにすることです。このため、CIOとCISOは、従業員が最新のテクノロジ、アーキテクチャ、ベスト プラクティスをアジャイルに活用できるようにすると同時に、各従業員に適切なセキュリティ対策を講じ、従業員の行動、アクセスする情報、使用する技術に対する管理を確立し、損失を防ぐことが求められています。
組織は、市場やマクロ経済状況の変化、消費者行動、サプライ チェーン、セキュリティ上の問題点に関連するリスクを理解し、抑制する必要があります。リスクを正確に評価し、迅速に緩和策を講じることができれば、ビジネスにおいて競争優位に立つことができます。このホワイトペーパーでは、特に知的財産の損失、ビジネス プロセスの中断、個人情報の損失、規制当局からの罰金などにつながりかねないセキュリティ上の問題点のリスクに焦点を当てます。セキュリティ リスクを算出するには、考慮すべき状況について以下の点を評価します。
このような状況下において、すべてのトランザクションに関連するリスクをほぼリアルタイムで計算し、適切な緩和策を講じて潜在的な侵害の影響を抑制することが課題となっています。
ビジネスを加速させるというニーズは、サイバーセキュリティのリスクを悪化させる新たな慣行につながります。この点について、以下で詳しく説明します。
相互接続されたビジネスは業務効率を高めますが、その結果として深刻なのは、どれか1つのセキュリティ ホールがそれらすべてに影響を及ぼすことです。攻撃者は、最も脆弱なリンクを見つけ、残りのリンクを介して拡散します。SaaSプラットフォームやクラウド インフラストラクチャの脆弱性やセキュリティの不備は、新たな攻撃ベクトルとなり、共有責任モデルでは早期検出と修復が困難になる可能性があります。
米国連邦、州、地方政府のさまざまな機関や複数の米国企業に対する執拗なサイバー攻撃の嵐を受け、ジョー バイデン大統領は2021年5月12日、国家のサイバーセキュリティの向上に関する大統領令を発令しました。この大統領令の重要な要素の1つが、政府機関がゼロ トラストの原則に従いサイバー攻撃に備えることです。バイデン政権はこの大統領令に続き、2022年1月26日に行政機関の長に向けた行政管理予算局(OMB)からの覚書を発表しました。このOMBからの覚書では、「連邦政府のゼロ トラスト アーキテクチャ(ZTA)戦略を定め、ますます高度化・持続化する脅威キャンペーンに対する政府の防御策を強化するため、2024会計年度(FY)末までに特定のサイバーセキュリティ基準および目標を達成するよう各機関に求めています。」1大統領令とOMBの覚書はいずれも、2020年8月に発行された米国国立標準技術研究所(NIST)のSP 800-207に記載されているゼロ トラスト アーキテクチャを指し、これに準拠するように政府機関に求めています。
政府機関や民間企業のオピニオン リーダーらが、ゼロトラスト アーキテクチャについて説明し、採用する最善の方法について助言する文書を発表しています。これらの文書に含まれるアイデアを以下に要約します。これらの文書のアイデアや提案の重要な本質は、すべてのトランザクションを調査してWho(誰が)、What Action(どのようなアクションを)、Whom(誰に対して)行おうとしているかを評価し、そのトランザクションに関連して算出されたリスクに基づいて、トランザクションを許可するか否かをリアルタイムで決定することであることに留意してください。
NISTチームは、その文書NIST SP 800-207において、ゼロ トラストの信条を列挙し、抽象的なゼロ トラスト アーキテクチャ(ZTA)を定義しています。2さらに、ゼロ トラスト アプローチのバリエーションを挙げ、抽象的なアーキテクチャを展開するさまざまな方法について説明しています。
この文書で説明されている主要な抽象概念は、互いに連動するポリシー決定ポイント(PDP)とポリシー実施ポイント(PEP)です。ポリシー決定ポイントは、ポリシー エンジン(PE)とポリシー管理者(PA)で構成されています。ポリシー エンジンは、信頼アルゴリズムを用いて、対象者にリソースへのアクセスを許可すべきかどうかの決定を行います。この決定はポリシー管理者によって実行され、ポリシー管理者はポリシー実施ポイントと通信して、新しいセッションの許可・不許可、既存のセッションの修正・終了を行います。さらに、信頼アルゴリズムのバリエーション、ゼロ トラスト環境のためのネットワーク コンポーネント、さまざまな使用事例や展開シナリオについても論じています。最後に、実装者が脅威を認識し、ゼロ トラスト アーキテクチャのコンポーネントを保護するために適切な手段を講じることができるように、攻撃者によるゼロ トラスト アーキテクチャの妨害方法について考察しています。
ゼロ トラスト計画の策定を支援する目的で、サイバーセキュリティ インフラストラクチャ セキュリティ庁(CISA)のオピニオン リーダーらは、ゼロ トラスト成熟度モデルを発表しました。3このモデルは、NIST SP 800-207文書に記載されている抽象的なゼロ トラスト アーキテクチャをベースにしています。著者らは、5つの領域を特定し、組織が各領域でゼロ トラストの原則に従って着実に推進していくよう推奨しています。その領域とは、(i)ID、(ii)デバイス、(iii)ネットワーク、(iv)アプリケーションのワークロード、(v)データです。また、5つの領域それぞれについて、可視化と分析、自動化とオーケストレーションの活用を推奨しています。
この文書では、前述したゼロ トラストの5つの基本的な柱すべてについて、高度な成熟度モデルを示し、さらに各領域を深く掘り下げています。組織は、この成熟度モデルを用いて現状を把握し、最適な状態に向けた反復的なプロセスを設定できます。
Solar Winds攻撃の発覚後、米国家安全保障局(NSA)は、文書「Embracing a Zero Trust Security Model(ゼロ トラスト セキュリティ モデルの導入)」で、サイバーセキュリティ チームにゼロ トラスト セキュリティ モデルを採用するよう助言するガイダンスを発表しました。4米国国防情報システム局(DISA)と米国家安全保障局のゼロ トラスト エンジニアリング チームの専門家らは、米国国防総省(DOD)ゼロ トラスト リファレンス アーキテクチャについて記し5、ゼロ トラストを採用する必要性を次のように表現しています。「DOD内外のデータ侵害によって露呈した脆弱性は、十分な情報に基づいたリスクベースの意思決定を促進する、新しく、より堅牢なサイバーセキュリティ モデルの必要性を示しています。」6
このリファレンス アーキテクチャは、ゼロ トラスト アーキテクチャに関するNIST SP 800-207文書で定義された抽象概念に基づいた推奨事項を示しています。この文書では、高度な運用モデルを提示し、その要素を詳細に説明しています。また、高度な成熟度モデルと、ゼロ トラストの原則をさまざまな分野に適用するための機能の対応付けも説明しています。これらの文書は、組織が現状を評価し、計画を立案するのに役立ちます。
「侵害を前提とする」姿勢を持ち、ゼロ トラストの原則に従うことは、組織のリスク管理とガバナンスの実践に役立ちます。トランザクションにかかわる行為者の「継続的な監視」と「明示的な検証」というゼロ トラストの原則に従うことで、組織はすべての行為者とその活動に対する動的なリスク スコアを構築できます。これは、既存のセキュリティ プログラムを強化するためにGartnerが使用を推奨している「Continuous Adaptive Risk and Trust Assessment」(CARTA)手法と一致します。リソースへのアクセスは最小権限しか認めないという原則を採用することで、侵害された場合でも損失のリスクを低減できます。また、継続的な監視と明示的な検証によって生成された情報は、コンプライアンス レポートの作成にも利用できます。
このセクションでは、ゼロ トラスト セキュリティのために企業が採用すべきツールや設計に関する戦略や決定の動機となる考え方として、考え方の体系の「Why(なぜ)」に焦点を当てます。実際、今日のゼロ トラスト ソリューションで採用されているすべての手法と要素技術の原動力は、4つの単純な主要原則に集約することができます。このセクションでは、これらの原則を挙げ、それらをアプリケーション開発の広範なライフサイクルに適用する方法、つまり、設計段階でこれらの原則を前もって検討する方法と、アプリケーションの展開や実行時に運用する方法について説明します。
ゼロ トラスト ソリューションが、基本的にシステム間のやり取り、すなわち「Who(誰が)、What(どのようなアクションを)、Whom(誰に対して)行っているか」に対する信頼性を構築するものと理解すると、やり取りに適した信頼レベルの構築は、4つの要素に分けることができます。
その名が示すように、ゼロ トラストの考え方は、「盲目的に信用せず、常に検証する」というものです。したがって、システム内のあらゆる行為者、すなわちシステムのやり取りにおけるWho(誰が)とWhom(誰に対して)は、次のことができなければなりません。
さらに、明示的に検証するという原則は、IDだけでなく、アクション、つまりトランザクションの内容にも適用することができます。よくある使用事例は、データベース クエリを行うAPIなど、アクションがAPIコールとして表現されている場合です。この例では、明示的に検証するという原則は、APIを呼び出す行為者の身元を確認するためだけでなく、APIに渡されたパラメータが適切な制約に適合しているかどうかを確認するなど、APIアクションの使用の正しさを検証するためにも使用できます。
成熟したゼロ トラストの考え方では、「証明」が絶対的なものであることはほとんどありません。ID認証情報が盗まれたり、デバイスが侵害される可能性があり、APIパラメータの制約も不完全であることが多くなります。したがって、ゼロ トラストのコンテキストにおける「信頼度」という用語は、証明されたIDまたはトランザクション パラメータが正当である可能性がどれだけ高いかを示すものと解釈されるべきです。「信頼度」のレベルは、トランザクションを許可するか、ブロックするか、あるいはさらに検査するかを決定する際の重要な要素の1つですが、唯一の要素と見なされるべきではありません。
トランザクションに関係する行為者について許容可能なレベルの「信頼度」が確立されると、ゼロ トラスト アプローチでは、行為者(通常は、要求元、「Who(誰が)」)にそのシステムで達成するように設計されていることを行うための必要最小限の権限セットのみを付与することを求めます。この原則は、「ポジティブ セキュリティ モデル」とも呼ばれるものを具体化したもので、デフォルトですべてのアクションを禁止し、システム運用に必要な特定の権限のみを付与するアプローチです。例えば、ある予約システムでは、匿名ユーザーがフライト スケジュールを閲覧することはできても、アプリケーションの設計要件に従って、匿名ユーザーがフライトを予約することは許可されません。
これらの権限は、個々の行為者に適用されることも、行為者のクラスに適用されることもあります。一般的に、アプリケーション利用者は人間の行為者または人間の代理として用意されたプロキシであり、「匿名ユーザー」、「顧客」、「パートナー」、「従業員」などのクラスに分類されます。信頼度の低いクラスの行為者は、通常、低い信頼度しきい値で認証をパスできますが、アクセスできるAPIは少数のより機密性の低いAPIに限られます。アプリケーション内の特定のサービスやコンテナなど、アプリケーションやそのインフラストラクチャの内部の行為者については、多くの場合、「コンテナおよびのみがデータベースにアクセス可能、のみがオブジェクト ストアに書き込み可能、およびは読み取りが可能」など、権限がさらにカスタマイズされています。
最小権限の実装で考慮すべき重要な点は、先見性を持ってよりカスタマイズした方法で適用するよう努めることです。7具体的には、成熟したゼロ トラストの実装では、すべての行為者または行為者のクラスに対して汎用的な権限セットを適用するのではなく、What(どのような)アクションが試みられるかをより詳細に把握する必要があります。例えば、大まかには「ファイルシステムへのアクセス権」を付与する場合でも、より厳しく指定すれば本当に必要な権限は「ファイルシステムの読み取り」である場合、厳しく指定することでポジティブ セキュリティ モデルを高品質で実装することができます。
最後に、ある行為者に許可した権限を絶対的なものではなく、認証がもたらす信頼度に基づくものと考えることで、最小権限のより高度な実施を、成熟した「明示的な検証」の実施と連動させることができます。この場合、証明された身元(Who(誰))に対する信頼度が最小限のしきい値を満たす場合にのみ権限が付与されます。このしきい値は、試みようとしているアクションに固有のものです。例えば、特に影響の大きいアクション(システムのシャットダウンなど)で、行為者が管理者である信頼度が90%以上である必要があるとします。この例では、シャットダウンが試みられたときにIDに対するシステムの信頼度が80%しかない場合、システムはアクションを許可する前に、証明されたIDに対する信頼度スコアを高めるために追加の検証を要求します。
明示的な検証や最小権限は重要な概念ですが、継続的に評価するという原則は、それらの原則が次のような意味で継続的に評価されなければならないという事実を示しています。
最後の原則は、健全なパラノイアを背景に、強い動機を持つ攻撃者を想定することに根ざしています。具体的には、「侵害されたと想定する」という前提であり、ここでの「侵害」とは、「(完全な情報と実装により)拒否されるはずのトランザクションが許可されたこと」と定義されます。この逸脱の根本原因としては、情報が不完全であったこと(例:未検出の不正な認証情報に由来する認証により高い信頼度スコアが誤って得られた場合)、実装の限界(例:権限として「オープン ネットワーク接続」が付与されているが、ネットワーク接続先の位置情報に基づいて識別する能力がないなど、付与される権限が十分に詳細に指定されていない場合)、ゼロ トラストの実装が不完全であったこと(例:内部で使用されるオープン ソースの脆弱なコンポーネントにゼロ トラストを適用していない場合)などが考えられます。
したがって、ゼロ トラストの考え方は、そのような侵害の影響を最善の方法で管理/最小化することにも対応しなければなりません。
この原則の実施方法は、他の原則よりも多様ですが、一般的には次のようになります。
ポリシーに基づく調整を選択した場合、その調整は、利用可能な静的ポリシー ツールのいずれかを利用して適用できます。ポリシーベースの調整の例としては、トランザクション単位のアクセス制御権限を制限すること(つまり、Who(誰が)、What(どのようなアクションを)、Whom(誰に対して)行うことを許可しないこと)、あるいは、行為者(または行為者のクラス)が特定の行為を行うためにはより厳しい「証明基準」を適用すること(つまり、MFAまたはより高い信頼度スコアを要求すること)などが考えられます。
一方、「最終手段」の追加層を使用するアプローチを選択した場合、この戦略はさまざまな粒度で実装することができます。最も粒度の細かい戦略は、特定のリスク/リターン比率を超えるトランザクションのみを正確にブロックすることですが、これにより追加の分析が必要になると、許可されるトランザクションの一部で許容できないレベルのレイテンシが生じる可能性もあります。一方、その行為者からの今後のトランザクションをサンドボックスに入れる、その行為者をシステムから完全に排除するなど、より粒度の粗い戦略を使用することもできます。極端なケースでは、ファイルI/Oのシャットダウンなど、より粗い緩和方法が適切な場合もあります。
もちろん、他の条件がすべて同じであれば、最終手段としての緩和策は細かい方が一般的に望ましいと言えます。しかし、多くの場合、利用可能なソリューション テクノロジの制約に基づくトレードオフが生じ、最終手段がないより、粗くてもある方が良いということになります。例えば、ランサムウェアの疑いがあればそれを阻止するために、ファイルI/Oを無効にするという粒度の粗い対策をとる場合、その行為者がチェックされずにシステム内で動作を続け、対策を講じなかった結果としてランサムウェアによってファイルシステムが暗号化されることを考えると、この対策による副作用の方が望ましいでしょう。
ゼロ トラストを使用した安全なアプリケーション開発の最良の出発点は、当然のことながら、開発の最初の段階です。ゼロ トラストの原則を運用するための基本的な原則を、アプリケーション開発プロセスの設計段階で組み込むべきです。したがって、CI/CDパイプラインに統合された運用可能なゼロ トラスト ソリューションのいかなる議論もこれらの基本的な要素の理解から始めなければならず、これらの要素は設計の検討事項として最優先される必要があります。
これらの基本的な要素の中核は、システム動作のやり取りの望ましい/意図された動作を、逸脱を検出してそれに対処するための十分な可視性および制御性と組み合わせて捉える必要があります。意図されたやり取りは、各行為者(Who(誰が))が各ターゲット(Whom(誰に対して))に対して行う望ましい一連のアクション(What(どのようなアクションを))を定義するために使用されます。とはいえ、意図するやり取りのパターンが不明なシナリオや環境もあるでしょう。そのような場合、組織は、より深く可視化することで、適切な一連のやり取りを「検出」し8、それをポリシーに成文化することができます。
例えば、今日のZTNAソリューションでは、アプリケーションの外部APIに対するID駆動型のアクセス制御に重点を置いていますが、これらのソリューションでは認証APIに対する可視性と制御性が必要です。また、クラウド ワークロード保護プラットフォーム(CWPP)のコンテキストでは、侵害されたコンテナ ワークロードを検出するには、各コンテナが実行するアクションを可視化する必要があり、さらにリアルタイムで修復する必要がある場合は、リアルタイムで可視化する必要があります。
以下は、設計プロセスに含めるべき基本的な検討事項に関する「バケット」の概要を示したもので、さらに掘り下げて、それぞれの重要なポイントについて考えるための具体的な質問も示しています。
この考え方の前提である「侵害の想定」によって具体化されているように、セキュリティ担当者は、強い動機を持つ攻撃者が悪質なトランザクション、すなわち完璧な世界であればポリシー ルールに従っているが許可されるべきではない、Who(誰が)、What(どのようなアクションを)、Whom(誰に対して)行うかの実例をうまく実行させることを想定しなければなりません。このような場合、前の「侵害を想定する」のセクションで説明したように、通常はトランザクションのパターンの観察とシステムの副作用に基づいて、このようなケースを発見できる効果的な「最終手段」のメカニズムを備えることが焦点になります。
しかし、IDの概念と同様に、特定のトランザクションが悪質かどうかに関する情報は決して完全ではありません。したがって、IDの場合と同様に、理想的なゼロ トラスト ソリューションは、トランザクションの正当性に対する「信頼度」スコアを報告する必要があります。例えば、あるデーモンが通常の10倍のファイル レートで10秒間読み書きするのを検出した場合、(悪意のある)信頼度スコアは70%になり、レートが100倍で1分以上継続するのを検出した場合は、信頼度が95%になるかもしれません。この例では、今後のファイル書き込みを禁止するという修復措置を講じた場合、誤った反応、つまり「誤検出」となる可能性があります(それぞれ30%または5%の確率)。したがって、修復するかどうかの判断は、誤検出のリスクと、悪質である可能性のある動作を許可した場合の潜在的な影響を考慮する必要があります。
この例でポイントとなるのは、ユーザーが認識できる形で修復措置を講じるかどうかの判断は、実際にはビジネス上の意思決定であり、疑わしい行動に関するすべてのリスク、コスト、リターンを考慮すべきであることです。トランザクションの煩雑さが増大すると、価値を得られなくなる確率が高まりますが、介入しない、つまり煩雑さを増大させないという選択は、侵害のリスクを生みます。したがって、このような場合に措置を講じる(または講じない)という意思決定は、次の3つの要素に基づく関数になります。
したがって、ゼロ トラスト戦略では侵害は発生するという事実を前提としなければなりませんが、周到なアプローチでは、許可されているが疑わしいトランザクションの是正について、リスク/リターン アプローチを採用します。このトレードオフでは、さまざまなアプリケーション トランザクションのリスクレベルと、修復措置を適用した場合の結果を理解し、リスクレベルが期待されるビジネス上のリターンを上回る場合にのみ、修復措置を適用することになります。
1 https://www.whitehouse.gov/wp-content/uploads/2022/01/M-22-09.pdf
2 https://csrc.nist.gov/publications/detail/sp/800-207/final
3 https://www.cisa.gov/zero-trust-maturity-model
4 https://media.defense.gov/2021/Feb/25/2002588479/-1/-1/0/CSI_EMBRACING_ZT_SECURITY_MODEL_UOO115131-21.PDF
5 https://dodcio.defense.gov/Portals/0/Documents/Library/(U)ZT_RA_v1.1(U)_Mar21.pdf
6 https://dodcio.defense.gov/Portals/0/Documents/Library/(U)ZT_RA_v1.1(U)_Mar21.pdf
8 または、少なくともシステムが必要としていると考えられる「適切と思われる」一連のやり取り。観察から得られた一連のやり取りが不完全であったり、何らかの既存のリスクが存在したりするリスクは常にあります。したがって、設計段階で事前に検討する必要があります。