AWSプラットフォームを他社の開発ベンダーへ直接触らせる環境について
AWSのプラットフォームを開発ベンダーに委ね、且つ昨今のテレワーク時代に沿ったコラボレーション環境に対するリスクと対策のヒントを得る目的で下記の本を購入
ゼロトラストネットワーク実践入門
ゼロトラストネットワーク[実践]入門 | 野村総合研究所, NRIセキュアテクノロジーズ |本 | 通販 | Amazon
とてもよくまとまっており、お勧めしたい
入門という事もあり、用語や考え方が丁寧に記載されている
私が得たい知見にたどり着くまでに頭が整理できました
後半に本書で、私がマーカを引いた箇所を引用し整理してものを記載します
感想
昨今AWSを利用した利用者へ提供するプラットフォームを検討する事が多いですが、観点は、いつもセキュリティと利便性で、本紙で触れていた
「戦略に寄与する効果と安全の土台を両輪で考える」
と同じでした。
また、利用者が自社以外へ依頼するケースも多いのでコラボレーションについては、まだまだ道半ばで、泥臭い作業を行う必要がある事を認知できました。
AWSに関わらず、クラウド利用はどうしても攻めと守りを考える必要がありますが、バランスを取る事が難しい。
情報漏洩から守るには、本紙のテーマ「ゼロトラスト」で全体最適を考える必要があり、クラウドの一端だけ見てはダメですね
ゼロトラストで社外とのコラボレーションにおいて、これだ!と思える策はなし
リスクを整理し、対策をとる。その内の一つがNDAの契約
これって、事故発生後の縛りで、予防的、発見的な統制ではない
私がマーカを引いた箇所を引用し整理
共創を支える協業環境
- コンテンツの共有
- 協業プロセスの共有
- ステータスの可視化
- 状況に合わせたコミュニケーション
- 適切なセキュリティ
セロトラストセキュリティは、下記全てをチェック
- アクセスの都度アクセス元を確認する
- アクセスの経路を確認する
- アクセス先を確認
SASE(Secure Access Service Edge)は下記で分類される
- インターネットからのリモートアクセス機能
ZTNA(Zero Trust Network Architect) - Webサイトを対象とした不正サイトとの通信の制御機能
SWG(Secure Web Gateway)
※URLフィルタリング - クラウドサービスの可視化・統制機能
CASB(Cloud Access Security Broker)
※クラウド通信の中身を解析、利用状況を可視化
AWS Organizations チュートリアル実施メモ「CloudWatch Events を使用したモニタリング」
外形監視で利用できるAWSサービス
外形監視で利用できるAWSサービス
外形監視とは
サービスを提供するサーバの外からアクセスを行い、ユーザーからの接続に見立てたアクセスで監視すること
ユーザーと同様の方法でアクセスして監視するので、「サービス監視」と呼ぶこともある
外形監視を利用したいシナリオ
利用できるAWSサービス
シナリオと選択するAWSサービスの関係
パブリック公開 | プライベート利用 | |
---|---|---|
Webサイト | Route 53 CloudWatch Synthetics |
CloudWatch Synthetics |
Webサイト以外 | Route 53 | なし |
監視軸のRoute 53
Amazon Route 53 をDNS機能と合わせて、DNSの切替を目的とした監視機能(Route53のヘルスチェック)がある
- エンドポイントをモニタリングする ← 外形監視
- CloudWatch アラームをモニタリングする
- 他のヘルスチェック (算出したヘルスチェック) を監視する
外形監視で利用できるRoute 53 機能「エンドポイントをモニタリングする」
特徴
- 世界各地のヘルスチェッカーからモニタリングされて、ヘルスチェッカーの成功数が18% を超えると正常判断される
- 下回ると異常と見なす
チェックの種類
検討ポイント
- 複数のヘルスチェッカーで18%以下にならないと異常と判断しない
⇒ 結果、異常検知に時間を要する - 外形監視ではパブリック公開されたシステムにしか利用が出来ない
- 複数のヘルスチェッカーで18%以下にならないと異常と判断しない
CloudWatch Synthetics
カナリヤ用Lambdaが裏で動作し監視する
- URLのページをロードしてモニタリングする
- APIエンドポイントにGET or POSTリクエストをモニタリングする
リンク切れチェッカー
作成されるリソース CloudWatch Syntheticsの作成で指定する名前
※この名前で作成されるリソース- IAMロール/ポリシー
CloudWatchSyntheticsRole-canary-name-uuid
CloudWatchSyntheticsPolicy-canary-name-uuid - CloudWatchロググループ
/aws/lambda/cwsyn-MyCanaryName-XXXXXXXX - Lambda関数
cwsyn-MyCanaryName-XXXXXXXX
- IAMロール/ポリシー
具体例)作成されるリソース名
- IAMロール/ポリシー
CloudWatchSyntheticsRole-test20220709-254-3e32985d41d2
CloudWatchSyntheticsPolicy-test20220709-254-3e32985d41d2
- CloudWatchロググループ
/aws/lambda/cwsyn-test20220709-579531c6-ce55-4
- Lambda関数
cwsyn-test20220709-579531c6-ce55-4c12-943e-3ba75a0fc99e
プライベート利用時の注意点
AWS Organizations チュートリアルからの学び
はじめに
AWS Organizationsの初学者が触った気づき、勘違いしたことを記載します。
AWS Organizationsの概念は理解していましたが実際に設計/構築の機械が乏しい為、理解を深める為のハンズオンを探しており最初は、このチュートリアルを実施しました。
AWS Organizations初学者の助けになれば幸いです
チュートリアル最初に実施した理由
- 提供が日本語 ※翻訳が不要
- シンプル
チュートリアルからの学び
- SCPの継承は、権限付与ではない ←これにフォーカス
- RootにSCPポリシーを適用しても、管理アカウントは影響を受けない
管理アカウント以外は、影響を受ける
※チュートリアルより脱線して確認 - Organizationsからメンバーアカウントを作成したAWSアカウントをメンバーより削除するには、7日間の経過が必要
※チュートリアルより脱線し実施して出来ない事象からの気づき - Organizationsで"メンバーアカウントの削除"は、Oranizations管理から外すことだった
※解約ではない - 解約は、Organizationsでは、"AWSアカウントの閉鎖" だった
- ルートユーザーの E メールアドレスは、アカウントを閉鎖しても再利用できない
作って/壊してを複数回実施する為には、事前に複数のメールアドレスを準備する必要がある - アカウントの閉鎖を抑止はSCPではできないので、IAMポリシーを利用する必要がある
※チュートリアルより脱線し実施 - 閉鎖後から90日以内なら、復帰が可能。ただし、能動的に復帰は出来ず、AWSサポートへ依頼が必要
※チュートリアルより脱線し実施
チュートリアル「組織の作成と設定」の構成イメージ
誤解していたSCPの継承
チュートリアルの動作確認で発生した疑問と理解できたこと
このチュートリアルで、OU:MainAppに含まれるAWSアカウント「上の図でsandbox03」で、禁止していない操作で、OU:ProductionでAllow以外の操作を実施したときに下記の疑問が発生した
- OU:MainAppには、OU:Productionと異なり、直接FullAWSAccessをアタッチしている(権限付与)ので利用できると思ったが、権限エラーで弾かれた
ドキュメントとクラメソさんのBlogを数回行き来して読み返して納得
- AWS ドキュメント
- クラメソさんのBlog
チュートリアルで出来る構成と挙動を言葉で伝える自身は無いので、イメージで表現
Appendix
-
AWS Organizations のチュートリアル
https://docs.aws.amazon.com/ja_jp/organizations/latest/userguide/orgs_tutorials.html - RootにSCPポリシーを適用しても、管理アカウントは影響を受けない
https://docs.aws.amazon.com/ja_jp/organizations/latest/userguide/orgs_tutorials_basic.html⇒Rootアカウントの制御できない理由:管理アカウントはSCPの対象外になる
EC2 Image Builder で設定するレシピ名とタグ設定の気づき
-
はじめに
2022/3/5 特別編 EC2 Image Builder ハンズオン に参加して操作時の備忘録です。
https://awsbasics.connpass.com/event/236691/
EC2のAMIを維持する頻度は減りましたが、利用する機会があると思って参加。
表題の内容をTwitterでつぶやき記録しましたが追従が手間なのと、せっかくなのでBlogを開設し、初回をこれに決めました。
続きを読む