基本的セキュリティ込みAWSクラウド構築手順

記事

IT・テクノロジー

ミコラボ

2024/12/20 09:32

次のような依頼を受けて、構築したシステムが３年経ちました。

当初は今のように整理された情報源がなく、AWSのWebサイトにも要約した記事がなかったので、手探りで行いました。

システム要件は以下のようなものになります。

①事業をスタートしたので、まずインフラを整備したい

②AWSクラウド上で、基本的なセキュリティを組み込みたい

③収支が安定するまではできるだけ経費を削減したいので、費用削減を考慮したい

■取り掛かり■

まず取り掛かりは、最低限のセキュリティサービスを実装して、AWSクラウドの基本を安定したものとしようということでした。

次のような基本的なセキュリティサービスを実装しました。

１．なにはともあれ、AWSアカウントの開設

ルートユーザと普段のメンテ作業を行うIAMユーザを用意し、IAMユーザも当初は管理者権限を持たせていましたので、MFAデバイスによる認証をセットアップしました。

以前は、パソコンとスマホで設定を同期できる「Authy」というアプリケーションを使っていました。

しかし、パソコンでの機能提供が停止してしまったので、代わりに現在はChromeブラウザのプラグインである「Authenticator」を併用しています。

２．AWS Shield(Standard/Advanced)、AWS WAFの実装を考える

標準機能として、AWSインフラにはデフォルトで、AWS Shield Standard が最初から稼働しています。

AWSドキュメントには、

多くの場合、AWS Shield Standard による保護で十分です。AWSサービスは、一般的DDoS攻撃に対して耐障害性を提供するように構築されており、AWS WAFや他AWSサービで補完すれば、適切な保護、軽減が達成されます。さらに、技術的な専門知識があり、レイヤー7攻撃のモニタリングと軽減を管理すれば、多くの場合では、AWS Shield Standard を選択することをお勧めします。

とあり、

AWS Shield Advanced は、大規模システム、ミッションクリティカル用途でのサービスで、月額料金3,000USDの高額であり、おいそれとは手が出せません。

その代わり、AWSのセキュリティ部隊である、DRTサポートという、24時間365日の専門サポートが受けられます。

これはAWS側が能動的に動いてくれるサービスであり、リスクイベント検出時、DRT側からユーザーに連絡してくれます。

さらに必要なインシデント管理、攻撃軽減措置を行ってもらえて、DDoS攻撃の影響で請求金額が大きく上がった場合にかかった費用がクレジットで返ってくる仕組み込みです。

ある程度、システム規模が大きくなったら、考えるサービスと言えると思います。

AWS WAFについては、費用は掛かりますが、専用アプライアンス製品では数百万となる機能が初期費用なしでコストも安く（月20ドル程度とアナウンスされている）、簡単に適用できるAWSマネージドルールもありますので、こちらを設定するのが良いかと思います。私は、「Core rule set（セキュリティ対策のセット品）」「PHP application」「SQL database（SQLインジェクション対策）」を設定しています。

３．GuardDutyとDetective

GuardDutyはAWSのセキュリティ講座でも、「すぐにセキュリティ対策ができる効果の高い機能なので、まずは入れて欲しい（AWS談）」と出てくる話しで、機械学習なども使って、リスク検知がされるもので、既存サービスへの影響もなく、コストも安価（30日間無料）なので稼働後はすぐに有効化します。（データ収集に48時間かかるので）

GuardDutyによって、有効性の高いセキュリティ対策が打てますが、リスクが分かったとして、そうなったときに次に考えるのは、どこから侵入されたのか、今、どうゆう状態になっているのか

が心配になるところです。つまり、GuardDutyで脅威通知が受けられた後に、Detictiveによって、収集しているデータから脅威の実態を掴みたいとなるのです。こちらももしもの場合を考えると有効化が必須でしょう。

４．InspectorとSecurityHUB

Inspectorはざっくりいうと「AWSのEC2 インスタンスの脆弱性診断を自動で行ってくれるサービス」です。

Webサイトを構築したEC2インスタンスで以前、Inspectorを実際に実施したことがあるのですが、SecurityHUBでの評価は、「AWS基礎セキュリティのベストプラクティスv.1.0.0」でセキュリティスコア34％、「CIS AWS Foundations Benchmark v1.2.0」でセキュリティスコア26％と散々な結果でした。つまり、そのままのOSイメージではリスクがそれだけ残っているということです。このときには、InspectorのCVE対策、SecurityHUBの標準対策から、AWSのWeb上の対策サイトを頼りに１週間かけて、対策を実施し、セキュリティ方針から理由を明確にした上で、チェックをはずして再評価をして、100％を取れましたが、こちらは覚悟を持ってやりことが必要です。

ちなみに私がセキュリティ対策を行った会社様では、API-Gateway を使ったシステムで、EC2インスタンスのチェックは必要なく、GuardDutyとDetectiveは有効化しましたが、InspectorとSecurityHUBはさわりませんでした。

さて、１年経ってからの事業計画も考慮した上での追加のセキュリティ対策が検討されました。

基本セキュリティ対策の評価、見直しとマルチアカウント対策の検討です。

■追加セキュリティ対策 AWS ControlTowerの導入 ■

当初のメインの事業はWebアプリケーションからのWebアクセスで、AWSクラウド上の認証情報を評価した上でのWebサービスの提供でしたが、毛色の違った監視モニタリングシステム、IOTを使った農業にフォーカスしたシステムなども動かす計画がありました。そのため、アカウント毎にIAMユーザを追加して、権限を管理して、メンテナンスを実施していくことの作業負荷が大変になることの心配が表出しました。アカウント毎の費用計算、かかる経費の案分などの経理作業も考えなくてはならないですし。

そこで、AWS ControlTowerを導入し、AWS Organization による組織とIAM Identity Center（以前は、SSOっていう名前でした）によって、複数のAWSアカウントへのシングルサインオンができる環境を用意することにしました。

AWS ControlTowerの導入手順は以下のように進めました。

１．ControlTowerの準備：管理アカウントの開設

２．ControlTowerの準備：IAMユーザの作成とMFA登録

３．ランディングゾーンの設定

４．組織を追加する（本番環境用OUのProd、開発環境用OUのTest）

５．新規アカウント追加

（監視モニタリングシステム／IOT農業用システム/教育用アカウント）

まずは、ControlTower環境は作成したのですが、なにぶん新しいサービス、試みなので、自前でもう一個のControlTowerの構築をやりつつ、既存AWSアカウントをControTowerに追加する作業を検討しました。一旦、自前システムで問題が発生し、解決した上で、本システムに臨んだんですが、だいぶ苦労しましたし、知見も溜まりました。このとき、アカウントプランをベーシックプランからでデベロッパープランに上げて、サポートに質問をしたり、あと目黒のAWS Loft Tokyoに作業に行ったときに、来ていらした技術エキスパートの方に教えていただいたりしました。

次が当時の移行計画です。

■移行計画■

【事前作業】

１．AWS Control Tower設定のため、管理アカウントのIAMユーザを作成する

２．既存移行アカウントと管理アカウントに、IAM権限「AWSControlTowerExecution」を追加する。

３．既存移行アカウントを、Root OU 配下へと移動する。

４．既存移行アカウントで、設定レコーダーおよび配信チャネルの削除（コマンド操作１分）して、Configを無効化する。

５．既存移行アカウントを、旧組織アカウントから外す（組織に含まれていると招待に反応しない）

【ControlTower移行本作業】※ 2023.06.24 作業完了

１．管理アカウントにログインし、既存移行アカウントを追加し、承認メールを送信する。

（既存移行アカウントにログインして、招待に対して、承認する）

２．管理アカウントOrganizationsで、既存移行アカウントを選択し、組織単位Prod OU に移動