【AWS-ゼロトラストモデル】AWSが考えるゼロトラスト指針

【AWSで実現するゼロトラストモデル】
https://aws.amazon.com/jp/blogs/news/zero-trust-architectures-an-aws-perspective/

上記HPから抜粋し整理したものを下記へ記載
※一部筆者による追記あり

# ゼロトラストとは
・従来のネットワーク制御やネットワーク境界のみに依存しない、または根本的に依存しない、デジタル資産に関するセキュリティコントロールを提供することにフォーカスした概念モデル
・ゼロトラストの世界では、従来のネットワークを中心とした信頼モデルが他の技術によって拡張または置き換えられる
⇒ユーザーのセキュリティ関連プロパティまたは属性など、様々なプロパティを基に評価される。「アイデンティティ」を中心としたコントロールへ

# AWSにおけるゼロトラストの第一の指針
「ネットワークとセキュリティアーキテクチャの二刀流」
概念モデルによってネットワークの場所への依存度は低下するものの、ネットワーク制御と境界の役割は、セキュリティアーキテクチャ全体にとって引き続き重要であるということ。
⇒両方を効果的に組み合わせて使用することによって得られます

■アイデンティティ中心のコントロール
例）AWS API エンドポイントとの対話に使用される AWS SigV4 リクエスト署名プロセス
CognitoID/ユーザプール認証

■ネットワーク中心のツール
例）VPC,セキュリティグループ,AWS PrivateLink,VPC エンドポイント


# AWSにおけるゼロトラストの第ニの指針
「文脈の曖昧性」
ゼロトラストが様々な文脈で異なる意味を持つ可能性があるということ
ネットワークの場所または境界によりセキュリティの課題を低減させるという基本的な技術的コンセプトにおいて、多くの異なるユースケースを含むことです。
⇒目的は組織によってことなる為、ユースケースも異なってくる。
一般的な例
・従業員の俊敏性（訳注:便利なサービスを迅速にとりいれて業務効率を改善していく等
・モビリティの確保（訳注：ブラウザとモバイルアプリ、インターネットを使用してビジネスシステムとアプリケーションにアクセスすること
・新しいクラウドベースのアプリケーション内部で慎重にセグメント化されたマイクロサービスアーキテクチャの作成


# AWSにおけるゼロトラストの第三の指針
「システムとデータ価値に合わせた柔軟性」
保護対象のシステムとデータの組織的価値にあわせて適用する必要がある。
うまく適用すると、ゼロトラストの原則は、特に重要なワークロードに対して、セキュリティの基準を大幅に高めることができます。
反対にゼロトラストの手法は、原則通り厳格に適用されてしまうと、アップグレードされたシステムや新しいシステムへの従来の技術の取り込みを制限し、労力に見合ったメリットがない組織に対して過度に負担をかけ、イノベーションを失速させる事になります。

まとめると
「対象システムとデータ価値を考慮してセキュリティレベルを決定しなければならない。」
標準化されたゼロトラストモデルでは制限が足かせになってしまう恐れがある。

# 現在の AWS におけるゼロトラストの原則と機能の例
AWSマネコンやAWS APIを利用して安全にAWSとコミュニケーションしていることが実例である。にも拘らず、クラウドベースのAPI使用はゼロトラストの議論の場に登場する機会が少ない。
これは AWS が最初から API を保護するため、このアプローチで先行していたためであり、おそらく、すべてのクラウドセキュリティについての議論の前提的なものとなっているからと想定されます。

AWS Signature v4 署名プロセスによって強化された トランスポート層セキュリティ（ TLS ）プロトコルの暗号強度を利用。
⇒AWS CLI/SAM/SDK/AWSサービス間のAPIアクセス等は意識せず勝手に署名してくれている。
基盤として通過するネットワークの信頼性がどうあれ、リクエストが適切に保護されることを知っているので、安心してリクエストを行うことができます。
参考：AWS API リクエストの署名
https://docs.aws.amazon.com/ja_jp/general/latest/gr/signing-aws-api-requests.html

# AWS によるゼロトラストジャーニーへの支援
お客様のゼロトラストへの移行を支援するために、ゼロトラストを構築する際にコアとして使える AWS クラウドで利用可能なアイデンティティ管理機能とネットワーキング機能を標準機能として提供しています

## ■ユースケースごとの説明

#### 1 コンポーネント間の特定のフローを許可し、不要な水平方向のネットワークアクティビティを排除
------------------------------------------------
AWSサービス名称[セキュリティグループ/PrivateLink/AWS SigV4 署名プロセス]
・主にマシン間の通信に重点を置き、コンポーネント間の特定のフローを許可
・二つのコンポーネントがネットワーク経由で相互に通信する必要がない場合は、これらのシステムが同じネットワークまたはネットワークセグメント内に存在していても、それらのコンポーネントは通信できないはず
⇒これにより、接続されたシステム間の接点が大幅に減少し、特に機密データにつながる不要な経路が排除
・PrivateLink を使用することにより、負荷分散されたエンドポイントを二つの VPC 間の狭い一方向ゲートウェイとして公開可能。S3 PrivateGateway等
・上記のゲートウェイにアクセスできるユーザーや受信パケットが到達できる場所をアイデンティティ ベースの制御により決定することが可能。
・反対方向にネットワーク接続を開始することは許可されておらず、VPC 間のルートも必要ありません。
現在、何千ものお客様が PrivateLink をセキュアなマイクロサービスアーキテクチャの基本的なビルディングブロックとして使用しています。
・Amazon API Gateway サービスを使用すると、AWS SigV4 と同様の強化されたインターフェイスアプローチを実現できます。
⇒複数の認証オプションの1つとして、AWS IAM のサポートを提供
⇒API を呼び出すことができるユーザーとその呼び出し元を定義する標準的な IAM ポリシーを作成でき、呼び出し元はAWS 認証情報を使用してリクエストに署名することでアクセスが可能


#### 2  社内アプリケーションへのスムースなアクセスを可能にします。
社員の社内アプリケーションへの摩擦のないアクセスを可能にし、セキュリティを損なうことなく、従業員のモビリティを向上させることです。
⇒VPN ベースのフロントドアを排除
Desktop As a sevice – Amazon Workspaces 
Appilcation As a service – Amazon AppStream 2.0
Verified Access (筆者追記）
https://dev.classmethod.jp/articles/aws-verified-access-preview/

一方で、社内 Web アプリケーションをインターネットに直接接続したいお客様もいらっしゃいます。これらのお客様には、AWS Shield、AWS WAF、Application Load Balancer と OpenID Connect (OIDC) 認証の組み合わせにより、完全に管理されたアイデンティティ対応型のネットワーク保護スタックが提供できます。


アプリケーションロードバランサーで認証を有効にすることで、（通常の負荷分散機能を超えて）、既存の ID プロバイダー ( IdP ) と直接統合して、ユーザーの認証作業の負荷を軽減し、IdP がもつ既存機能（強力な認証、デバイスのポスチャー評価、条件付きアクセスおよびポリシーの強制）を活用できます。この組み合わせにより、社内のカスタムアプリケーションは SaaS アプリケーションと同じくらい柔軟になります。最新のアイデンティティ標準を採用した共通のセキュリティモデルでアプリケーションポートフォリオを統合しながら、従業員は SaaS と同じくどこでも作業できる柔軟性を享受できます。
参考：ALBユーザー認証（Cognito IdPフェデレーション等）
https://docs.aws.amazon.com/ja_jp/elasticloadbalancing/latest/application/listener-authenticate-users.html
参考：Cognito Okta SAML連携
https://aws.amazon.com/jp/premiumsupport/knowledge-center/cognito-okta-saml-identity-provider/




#### 3  IoT などのデジタルトランスフォーメーションプロジェクトの保護
デジタル変革プロジェクトのセキュリティ確保
最初の二つとは非常に大きく異なります。
コネクテッド・カーを考えてみましょう。コネクテッド・カーはモバイルネットワークとインターネットを介して重要な計測ストリームをクラウドベースの分析環境に中継し、処理と洞察を得ます。
これらのワークロードは常に従来のエンタープライズネットワークの外部に存在しており、その状況に対応するセキュリティモデルが必要です。
AWS IoT サービスファミリは、フリート内のすべてのデバイスに固有のデバイス ID を発行し、これらの ID と関連するアクセス制御ポリシーを使用して、クラウドとの通信方法と対話方法を安全に制御するためのスケーラブルなソリューションを提供します。
これらのデバイスのセキュリティは、AWS IoT Device Defender、無線でのソフトウェアアップデート、さらにはオペレーティングシステム全体のアップグレード (現在は FreeRTOS に組み込み済) を使用して簡単に監視および維持でき、長期にわたってデバイスを安全かつセキュアに保つことができます。
今日のビジネスにすぐに適用できないかもしれませんが、今後、レイテンシーを最小限に抑え、ユーザーエクスペリエンスを向上させるために、ますます多くの IT ワークロードがエッジに近づくにつれ、このユースケースは普及していくでしょう。


続く。