1.1　機能要件 ガードレールとは

　前提としてガードレールの概念を確認しましょう。ガードレールとは、AWSが提唱しているセキュリティー防御のシステムです（コントロールとも呼ばれています）。

　・従来型の防御「関所」

　従来型のセキュリティー防御の概念は関所にたとえられます。事前にセキュリティーリスクの発生しうる箇所をあらかじめすべて閉じ、セキュリティー担当部署に申請をし、通らせてもらう、ホワイトリスト形式の概念です。

　非クラウド、言い換えればオンプレミスの時代の運用は、関所で問題ありませんでした。なぜなら、従来のシステム構築の分担は、サーバー、ネットワーク、アプリケーションと構築者が分かれており、そのくくりと同じ単位で、物理的に機器が分かれていることがほとんどだったからです。主にネットワーク担当、たまにサーバー担当が物理的な機器構築・運用に必要なホワイトリスト設計に責任を持ち、関所の承認を得ることで、安全なシステムが構築できていました。

　・クラウドの防御「ガードレール」

　ガードレールは、全ての開発者に対し、セキュリティーリスクに繋がる危険な操作を操作できないようにレールを敷いて、防御する補助的概念です。危険とまで即判断できない操作に関しては、怪しい操作を検知したことを各所に連絡し、必要に応じて修正します。

　AWSでのマネージドサービスの通信は、構築者が関与できないプライベートアドレス外、つまりAWS内部・マネージドサービス範囲での通信が多々あり、プライベートアドレスネットワークからAWS内部へ通信するための設計が数多く存在します。従来の区分のアプリケーション担当者も、従来の区分のネットワーク設定を行いたい場面が出ます。関所型方式時のように、都度都度書類や申請で通信許可設定を行うと、開発期間上、予期せぬタイムロスが発生致します。そのため、どうしてもセキュリティーリスクが高い操作だけ禁止（レールを敷いてできないように）し、危険な操作には警告を出す、ガードレールにて監視することが推奨されています。

　もし、従来型の関所型セキュリティー防御をJTCの権力を持つ者から要求された場合には、この概念から説明し、関所型はいかにクラウド構築に適さないのかの説明から、要件定義を作成しましょう。

1.2　機能要件 ガードレールの機能

　ガードレールの機能は、この本においては「予防的統制」「発見的統制」ふたつに分けて考えます。Amazon Web Services (AWS) 規範ガイダンスとしては2024年3月現在、¹予防的コントロール、プロアクティブコントロール、検出的コントロール、レスポンシブコントロール の4種類提唱されています。前者ふたつが「予防的統制」(プロアクティブコントロールは設定に応じて発見的にも使用可能)で、後者ふたつが「発見的統制」です。それぞれ何のサービスを使って統制を図るか、発見をした後何をするかによって分類される区分の違い、と捉えてください。設計コストや動作コスト、運用コストに応じて、それぞれのJTCに適したコントロールを使っていきましょう。

　・予防的統制

　侵入禁止札を立てたり、はみ出さないようにレールを敷くような統制です。運用者は、システムの構築・運用を決められたレールの範囲内で実施します。もし誤ってセキュリティーリスクの設定を行おうとしても、そもそも設定反映自体が構築者にはできないように認可設計を行います。

　・発見的統制

　制限速度を制定して、制限を超えると警告、事故をする前に運転手に気づいてもらうような統制です。様々なルールを設定し、危険判定を自動でリアルタイムに通知・または自動で修正対応させます。

　この2点の中身を機能要件として考えていきます。JTCで大事なのは、極力要件定義の段階で、偉い人に設定内容の許可をもらい、事前に予算捻出をしてもらうことです。どういう機能をどういう風に設定するから、安全なのです、とまとめる要件定義をする必要があることを念頭においてください。設定した後に後出しでお金を出して、と言うと通常はマジ切れされますので、ご注意ください。

1.3　機能要件 統制要件の抜き出し方

　まず、ガードレール統制要件を決めるために、セキュリティールールの要件から抜粋しましょう。どういったことから守るのか？というセキュリティールール要件を抜き出します。JTCだと、ISO27001² やISO9001³ を取得している企業も多いかと思います。その過程でできたセキュリティールールを使用します。

　規格とセキュリティールールの関係性は、たとえばISO27001は会社に規格基準に則ったルールがあり、随時運用されていることを前提に承認が下りる、企業に対する情報セキュリティーマネージメントシステム（ISMS）の国際規格です。その規格ルールとは

　・機密性

　限られた人だけが情報に接触できるように制限をかけること。

　・完全性

　不正な改ざんなどから保護すること。

　・可用性

　利用者が必要なときに安全にアクセスできる環境であること。

　の3点を実現させるセキュリティールールです。

1.3.1　抜粋したルールを分類する

　抜粋した国際規格、JTCで今まで運用・適用されていたセキュリティールールに対し、ガードレールにおいても、予防的統制か、発見的統制かどちらに振り分けるのかを分類させましょう。具体的には予防的統制は、「攻撃を受けることを防ぐもの」、発見的統制は「攻撃を受けても事業が持続できるようにする設定もの」で分けるとよいでしょう。

　なお、大事なこととして、発見的統制「攻撃を受けても事業が持続できる対策」に関しては、守られないと事業的にインパクトが大きいものかどうか、順位付けをして対策を分類していくことです。

　理由としては、どんな設定変更や事象も全て検知、通知をしたり対策をする設定は、理論上ではできるのですが、数多く設定すればするほど料金・設定工数がかかり、通知を受け取る側の運用負荷も大きくなります。本当に大変なことになります。そのため、このガードレール導入を決めた責任者が「どこまで守られてほしいか」を判断してもらうために、LV分けの判断材料を用意するためです。自分が責任者の場合は、予算とトレードオフで自分で決めましょう。

1.3.2　抜粋すべきルールセキュリティールールがないJTCの場合

　ガードレール導入プロジェクトの会社や、自社にルールが制定されていない場合には、CIS Controls⁴ や、IPAの情報セキュリティー10大脅威⁵を参考に考えましょう。CIS Controlsとは、組織で最低限行うべきサイバー攻撃に対応するためのガイドラインです。内容によってガードレールとは言い難い内容（ベネトレーションテスト）も含まれますが、それ以外はガードレールでも実装可能です。参考にするガイドラインも、セキュリティールールと同じく分類分けし、順位をつけて、要件を抜き出しましょう。

　なお、CIS Controls自体は英語で出ています。日本語での解説サイトもいくつかありますので、複数DLし、比較・参考にしましょう。

1.4　機能要件 上司に説明するために

　要件定義ができた！ さぁ基本設計にとりかかるぞ！ ではなく、基本設計の前に大事な作業があります。報連相です。

　設計手戻りを防ぐため、ガードレールを導入することで、今後どうセキュリティーを守る体制になるのかを上司に説明し、方針の合意を取りましょう。もし自社ではなく、他社からの設定依頼の場合には、発注元担当、と読み替えてください。

1.4.1　機能要件 説明・合意取得にて確認すべき内容

　・予算感

　要件として大事な観点は、自分で一旦分類した「攻撃を受けても事業が持続できる対策」について、どういう方針で対応するか、です。

　お金・時間を死ぬほどかけてやってもいいのか、予算ありきでできる範囲の部分までで切ってもいいのか、ざっくりした判断ポイントを仰ぎましょう。その場合、予算も具体的に聞いておきましょう。

　なお、説明する中で「このシステム、最終的にいくらになるの？」と聞かれると思います。ガードレール、特に発見的統制は、設定項目の分析数・ログ量に応じて増加する、従量課金のサービスを利用します。そのため、”基本設計で実施するPoCの結果に応じて確認します” と、この場では濁しましょう。PoC料金も聞かれると思いますが、設定時に、また承諾もらいに説明に来ます！ で押し切りましょう。要件定義合意も終わってないのに、料金計算なんかできるわけがないです。

　・順位付けの一致不一致

　「攻撃を受けても事業が持続できる対策」について、要件抜粋内でLV分けを行いました。そのLVと、上司が大事にしたい点が一致しているかどうかを確認しましょう。

　たとえば、”ランサムウェア対策については必須”なのか、”法令でログ3年保存はやっていないとだめ”なのか、”万が一障害が起きたときにすばやく復旧するのが一番”、なのか順位付けの再確認をしましょう。なお、全部大事・選ぶことができない、上司もいるかと思います。その選択は予算と期間が潤沢にあれば可能ですが、そこは普通のJTCの場合、切るべきラインが必ずきますので、とにかく選ばせましょう。予算に糸目をつけない！ と念押ししたにもかかわらず言いきってくれたら、それはとてもよいJTCです。

　・例外について

　開発系だったり、サービスイン前のガードレールは緩くしてもよいのか？ 等は確認しておきましょう。予防的統制は厳しければ厳しいほど統制者目線では安全ですが、開発スピードが落ちるので、開発中は多少緩めにする設計も悪くはありません。その対応が可能かどうかは、あらかじめ合意をとるべきです。

1.5　非機能要件

　次に非機能要件です。非機能要件は、IPAが公開している非機能要件グレード⁶が網羅性があり、よい内容です。非機能要件グレードの6つのカテゴリーに準じて、定義していきましょう。

1.5.1　可用性

　可用性は、システムサービスを継続的に利用可能にする要求です。セキュリティールールの中で「可用性」というワードが仮に存在した場合、通常は個別システムの可用性を指しています。この節の「可用性」は、ガードレール自体の可用性の話です。

　たとえば長時間利用できるか・メンテナンスがクライアントの利用に支障を及ぼさないか・障害発生時の復旧手順・スケジュールが事前に用意されているかを検討し、設計構築します。稼働率、目標復旧水準、大規模災害に関しての定義もあわせて行います。

　ガードレールに関連するサービスは、AWSのマネージドサービスを駆使して構築するため、AWSのサービス障害によって停止の可能性があります。ただし、ガードレールの特性上、万が一ガードレール自体が止まっても、稼働中のシステムの動作には影響ありません。そのため、可用性の要件としては対象外、「AWSのサービスの復旧に準ずる（別リージョンや別クラウド上での動作は行わない）」と記載が一般的です。

　ただし、AWSサービス側に万が一の状況が起きてしまい、設定した値が飛ぶ可能性は、完全なるシステムは存在しないのと同様、完全なる0とは言えません。限りなく0に近いですが、設定した値はどこかに控えることを要件としておくと安心です。

1.5.2　性能・拡張性

　性能・拡張性は、システムの性能および将来的なシステム拡張を可能にする要求です。性能について、適宜自動拡張を謳うAWSマネージドサービスは、AWSが処理量に応じて物理的な拡張を自動で行うため、「性能要件は考慮不要」と明記しましょう。

　拡張性については”AWSハードリミット” の値に対し、一部考慮の必要が出てきます。ですが、詳細設計パラメータを設計するまで、どういったハードリミット要件が存在するかは現時点で不明です。そのため、ここでは「AWSのマネージドサービス、ハードリミット要件については、詳細設計の内容に応じて、必要な拡張設定をあらかじめ行う」と明記しましょう。

1.5.3　運用・保守性

　運用・保守性は、システムの運用と保守のサービスに関する要求です。セキュリティールールの中でも「可用性、保守」というワードが出ていましたが、ここの「非機能要件」はガードレール自体の可用性や保守の話です。

　たとえば、ソフトウェアの利用目的に合わせて稼働時間を確保可能か、データのバックアップを適切な形式・頻度で取得したか、運用時の役割分担や手順のマニュアル化などです。

　・運用時間

　ガードレールの運用時間は、24時間365日（ただし障害によるシステム停止を除く）です。攻撃は夜間に行われるかもしれません。常時設定・運用が必要です。

　・バックアップ

　可用性の部分で述べましたが、設定値のバックアップだけしておきましょう。

　・基本的な役割分担

　ガードレールに関する内容を、誰がどう運用するかの要件も、あなたの想定を明記しておきましょう。

　具体的には運用設計内で設計しますが、要件定義内では関係者を羅列しましょう。JTCだと、関係者としてはガードレール設計者であるあなた、社内のコンピューターに関するセキュリティー事故の対応チーム（CSIRT）、今まで境界線防御をしていたFirewallを運用していたオンプレミスＮＷチーム、普段各アカウント上に作られたシステム運用のみをしている運用チーム、各アカウント上に作るシステムを開発した方々、関係者として挙げられます。定期メンテナンス、非定期メンテナンス、障害対応は誰がやるべきかを設計する、と定義しましょう。

　・運用監視

　ガードレールから上がってきたインシデントを誰に振るか、と障害対応の2点です。後者は「AWSのサービスの復旧に準ずる」ので、対応不要ですが、インシデントに対しては設計が必要です。

　・マニュアル化

　マニュアルについては、ガードレールの設定のみ準備し、各インシデントは都度判断・作成する、と明記してください。理由としてはガードレールのサービスはAWSが随時拡張しており、検知するインシデントも増えていきます。勿論一定のインシデントのみの検知設計もできなくはないですが、随時新しいサイバー攻撃が生まれている昨今、現時点でわかっているものだけの対応では不足します、拡張するガードレールに乗っていきましょう。

1.5.4　移行性

　現行システム資産の移行に関する要件です。これは、今までガードレールという考え方で何か運用をしていない限りは、対応不要です。

1.5.5　セキュリティー

　情報システムの安全性の確保に関する要求です。ガードレール自体にクレデンシャル情報はないので、考慮不要です。

　通常のAWS通りの、運用をする人だけに権限を与える、最小権限の原則に則った権限設定程度で考えましょう。

1.5.6　システム環境・エコロジー

　システムの設置環境やエコロジーに関する要求です。これは「AWSのSOCレポート⁷等⁸公開レポートに準ずる」と一文入れておけばOKです。JTC自体に新しい機器を設置しないガードレールで、新たにエコに対応する要件は出てきません。ガードレールを設定する前にAWSを利用されているJTCがほとんどだと思うので、導入当初の資料を参考に引用しましょう。

1.6　非機能要件 上司に説明するために

　非機能要件も簡単に説明しましょう。機能要件と違い、それほど確認すべき項目はないですが、説明は必要です。

1.6.1　非機能要件 説明・合意取得にて確認すべき内容

　・上司が想定する運用メイン担当者

　基本的な役割分担内で羅列した組織に「運用メインで担当すべきはどの人ですかね……」と、会社の組織体制を聞いておきましょう。

　・運用交渉の協力

　自分が知らない人に運用を任せる場合には、通常引き継ぎ説明が必要なので、なるべく早めに協力してもらえるかどうか、上司ないし発注元からもプッシュしてもらえるかどうかを聞いておきましょう。JTCの場合、上の権力からでないということを聞いてくれない人は本当にいっぱいいます。将来の自分を助けると思って、確認だけはしておきましょう。

　なお、自分の会社ではない組織、たとえば発注元に対してのガードレール導入の場合、運用を他組織にお願いするお話は雇われ技術者には到底無理なので、発注元にしてもらうようお願いしましょう。契約上、雇われ人、SIerやSES準委任契約、派遣契約ではできることとできないことがJTCにはあるのです。