【基本設計編part2】開発未経験がクラウドを企業に導入するプロジェクトごっこをしてみた~その3~

# はじめに
２２年度文系学部卒のたいきです。この記事では、システムの開発経験もないのに、見よう見まねで「プロジェクトごっこ」をしていきます。
・保有資格 : 応用情報技術者・AWS-SAP
・プログラミング言語:軽くPython
# 本記事について
　前回記事で定めた要件定義をもとにして、今回は本プロジェクトごっこの基本設計をしていきたいと思います。下記が前回記事です、よかったら読んでみてください。
[【明日から社会人】開発未経験がクラウドを企業に導入するプロジェクトごっこをしてみた~その2~【要件定義編】](https://qiita.com/Ishii_Taiki/items/f4912849a5d26fbcdcaf)
本企画の最初の記事から読んでいただける方は[コチラ](https://qiita.com/Ishii_Taiki/items/e3035c12b31385f8156b)
前回の[システムの基本設計](https://qiita.com/Ishii_Taiki/items/244308ef3bd925f4f253)の続きとして、クラウド環境構築の基本設計をしていきます。
本記事は、下記のサイトを参考にして基本設計を行わせていただきました。
> https://pm-rasinban.com/rd-write
> 仕様書・設計書テンプレート | 基本設計書・詳細設計書サンプル

# クラウド環境構築の基本設計
以下の要件定義書に記した、要件ごとに設計していきます。

・1.セキュリティの基準とAWSのベストプラクティスに沿っていない場合を検知する。
・2.脆弱性・インシデントの自動復旧による発見的統制
・3.Organizationsとの統合によるセキュリティの一元管理
・4.ログ収集の一元化
・5.AWS SSOを利用した既存のアクティブディレクトリとの統合

## 1.セキュリティの基準とAWSのベストプラクティスに沿っていない場合を検知する。
CloudTrail・Amazon Config・Guard Dutyなどの情報収集リソースを起動し、Security Hubで脆弱性やFindings(検知)を管理。
下図がAWSリソースの概要
![security_resource.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2608302/3cc99e29-2228-f2db-c5b4-4eabfd0908d8.png)
## 2.脆弱性の自動修復
特定の脆弱性を発見した際に自動的にその脆弱性を自動修復する。
以下が自動修復アーキテクチャ
こちらのアーキテクチャは、自力での１からの実装は自分では不可能なので、AWS公式さんの実装ガイドを参考にさせていただきます。
![quoted.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2608302/514fa876-9def-2c86-5853-bc3d63ac13e4.png)
> AWS Security Hubによる自動対応と修復
> https://aws.amazon.com/jp/blogs/news/automated-response-and-remediation-with-aws-security-hub/
## 3. Organizationsとの統合によるセキュリティの一元管理 
Security Hubを全アカウントに適用し環境を一元的に管理し、統制します。アカウントをグループ化（OU化）してワークフローを整理し、ガバナンスのためにアカウントまたはグループ（OU）にポリシーを適用します。加えて、統制アカウントの支払いを一元化できます。
以下が組織体制です。
![スクリーンショット 2022-04-02 144459.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2608302/986cddc3-1b14-d770-2831-c7a3a38d8d33.png)
OrganizationalRoot unitは、管理アカウント以外を一括制御するためのもの。
![organization1.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2608302/3d8db41a-d3c2-fc63-9228-199a178e9984.png)
![organization2.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2608302/01ec7a8a-66e8-250a-0d37-aec665764b90.png)
![organization3.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2608302/c489a02f-97d2-ea0e-c69f-cfad7b194c6b.png)
![organization4.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2608302/082655f3-0149-198e-1e71-073a651d0c41.png)
# 4. 操作ログ・アクセスログの全てのログを特定のS3バケットにて集中管理を行う
![logging.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2608302/298634f0-3ec8-72df-dd29-c6cf96ef05f4.png)
フェイルオーバー先にもS3バケットを作成し、データをレプリケーションする。そして、同様のアーキテクチャを事前に用意し、DR時も変わらずロギングを続ける。
Kinesis Data Firehose：データをまとめて、かつ圧縮して転送可能なサービス。これにより、直接S3へログを送信するよりもコストを削減できる。

# 5.AWS SSOを利用した既存のアクティブディレクトリとの統合とSSOの実装
ユーザはユーザポータルに普段使っているユーザ名とパスワードでサインインして、管理者がアクセスを許可したAWSアカウントやアプリケーションへのアクセスを可能にする。
オンプレミスActive Directoryの情報を参照し、その情報を利用してAWS SSOがクラウド上で認証情報を管理する。
![SSO.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2608302/64e18c73-bb5d-7e58-2e3b-070cfe665e82.png)

# おわりに
改めてになりますが、詳細設計に関しては今回作成しません。理由としましては、私自身がアーキテクチャの知識しかなく開発の知識が全くなく、利用するコードなどの想像が全くできていないからです。開発は、その場その場で壁にぶつかりながら試行錯誤をしながら開発していきます。今後ですが、次回記事で大まかな開発工程を決めていきます。その後は、その開発工程に沿って実際に開発していくことになりそうです。引き続きよろしくお願い致します。
PS.無事社会人になれました。
続編！はこちらです「[【開発工程決定編】開発未経験がクラウドを企業に導入するプロジェクトごっこをしてみた~その4~](https://qiita.com/Ishii_Taiki/items/aa36f46628242ab1f02f)」