web-dev-qa-db-ja.com

AWSセキュリティ-開発テストのステージング本番環境

現在、すべてのシステムは従来のデータセンターと従来のネットワークトポロジにあります。

AWSへの移行を計画しており、そうすることで、開発/テスト/ステージング/本番環境を実装する方法を理解しようとしています。我々がすべき：

1）環境ごとに別々のAWSアカウントがあり、統合請求を使用していますか？

2）環境ごとに個別のVPCを作成しますか？ -高可用性のために複数のリージョン/アベイラビリティーゾーンが必要になる可能性が高いことに注意してください

3）環境ごとに個別のサブネット。または、Webサーバー/データベースサーバー/管理管理タイプのサーバーに個別のサブネットを使用する必要がありますか？

私はいくつかのグーグルと読書をしました、そして私は明確な答えを見つけることができません。いろいろな意見が混じっているようです。私が見つけたほとんどの投稿は必ずしもセキュリティ志向の人々ではなかったので、ここで尋ねようと思いました。

クラウドセキュリティ、ネットワークトポロジ、およびAWSを使用したネットワークセキュリティへの階層化アプローチのために他の人々は何をしていますか。

cloud-computingaws
9
Brad

AWS DevSecOps指向の経験に基づいて、1、2および3がおそらく最も効果的な解決策でしょう。

1）Have separate AWS accounts for each environment and use consolidated billing?完全に同意しますこれは、2017年の初めにAWSサポートから得た公式の記録でした。マルチアカウントアーキテクチャuser-mgmt、security-audit-logging、shared-resources-services、project-appアカウントを分離すると、blast radius最大限に。

AWSの組織構造は特定の要件に依存するため、以下のAWS公式リンクを参照として検討してください。

その自動化のために、AWS python SDK + bashまたはterraform）のようないくつかの代替手段があります（組織のアカウントが10未満の場合、AWS Webコンソールから管理するのは非常に簡単です） 。ただし、IDをIaCに保つ（TerraformまたはAWSクラウドフォーメーションを使用したInfraAsCodeアプローチは、私たちの観点からはほとんど必要です）。

2）Create separate VPCs per environment? - keep in mind we'll likely want multiple regions/availability zones for High AvailabilityマルチアカウントAWS Orgアプローチを実装することを想定しているため、アカウントx環境ごとに少なくとも1つのVCPがあります。特定のリージョンに1つのVPCがある場合、高可用性、自己修復、冗長性、および復元力には複数の可用性を使用するので十分です-ゾーン（マルチAZ）構成（例：us-east-1a、us-east-1b、us-east-1cは3で拡張されます）。ネットワークのパフォーマンス（レイテンシ- https://www.cloudping.info/ ）とコスト（N.Virginia-us-east-1、Ohio-us-east- 2、Orego-us-west-2- https://www.concurrencylabs.com/blog/choose-your-aws-region-wisely/ ）。

心に留めておくべき投稿手順：

マルチリージョンも必要かどうかを評価するために、次の情報を検討してみましょう。公式ドキュメントで定義されている-> https://docs.aws.Amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.htmlAmazon EC2は世界中の複数の場所でホストされています。これらのロケーションは、リージョンとアベイラビリティーゾーンで構成されています。各地域は個別の地理的エリアです。各リージョンには、アベイラビリティーゾーンと呼ばれる複数の隔離された場所があります

したがって、地域内であるが隔離された場所（データセンター）内でHAアプリをホストする場合は、地域ごとのAWS SLA of：

  • AWSは商業的に合理的な努力を払って、含まれるサービスをそれぞれのAWSリージョンで利用できるようにし、月間稼働率を99.99％以上にします
  • 在庫状況：99.99％
  • 耐久性：99.999999999％（ストレージクラスによって異なります）

コンプライアンスフレームワークのためにMulti-Region active-active methodが必要な場合：次に、マルチリージョンアプリケーションを設計し、DNSを使用してそれらの間で通常のバランスを取る本番ステータスでは、DNSの重み付けを調整し、利用可能なすべてのトラフィックをAWSリージョンに送信できます。これは、Route53またはヘルスチェックメカニズムと負荷分散を提供するその他のDNSサービスで自動的に実行することもできます。マルチリージョンアーキテクチャの場合は、次の点を考慮してください。 https://aws.Amazon.com/blogs/aws/latency-based-multi-region-routing-now-available-for-aws/

ref-sla-links：

3）Separate subnets per environment. Or should we use separate subnets for web severs/database servers/management-administration type servers?プロダクショングレード環境に必要なマルチAZデプロイを取得するには、少なくとも3つのプライベートサブネット（冗長なAWS Nat-GWを介して-少なくとも2つ）それらは異なるaz）と3つのパブリックサブネット（インターネットGW経由）です。もちろん、それぞれが個別のAZにあります。また、Dev/Qa/Stgの場合（コスト効率のために単一のアカウントに統合できます）、異なるAZに少なくとも2つのプライベートサブネットと2つのパブリックサブネットがあります。これはEC2とRDSに適用されます（ https://docs.aws.Amazon.com/AmazonRDS/latest/UserGuide/Concepts.MultiAZ.html ）、S3バージョニングとマルチリージョンレプリケーションには推奨されます

前述の内容に基づいて、リファレンスアーキテクチャを紹介しましょう。

AWS orgマルチアカウントアーキテクチャ

  • user-mgmt-acct（組織間のアプローチに基づく集中iamの役割-アカウントごとのiamの役割がまだ必要であると想定されています）。
  • security-audit-logging-acct（cloudtrail、vpc-flow-logs、alb、cloudfrontアクセスログなどのログを集中管理する集中アカウント一元化されたファイアウォールマネージャーのセットアップ、またはその他のAWSサービスやセキュリティ監査ツール）。 注：アーキテクチャを簡略化するために、前述のアカウントを1つのアカウントのみに統合できます。
  • shared-resources-services-acct1 x VPC + 2 prv-sub-nw + 2 public-sub-nw（multi-az）+ 1 x nat-gw + project-X-app-acctsを使用したVPCピアリング（ここでは、ソフトウェア開発共有ツール、VPNソリューション、プロメテウスやグラファナなどの監視ツール、CI/CDサーバー、おそらくジェンキンス、ドローン、スピンネーカー、など、多目的インフラK8sクラスター、ELKのような集中ログソリューション、またはセルフホストSplunk）。
  • project-A-dev-stg-acct：1 x VPC + 2 prv-sub-nw + 2 public-sub-nw（multi-az） + 1 x nat-gw + shared-resources-acctによるVPCピアリング
  • project-A-prod-acct：1 x VPC + 3 prv-sub-nw + 3 public-sub-nw（multi-az）+ 2 x nat-gw + shared-resources-acctを使用したVPCピアリング
  • project-B-dev-stg-acct：1 x VPC + 2 prv-sub-nw + 2 public-sub-nw（multi-az） + 1 x nat-gw + shared-resources-acctによるVPCピアリング
  • project-B-prod-acct：1 x VPC + 3 prv-sub-nw + 3 public-sub-nw（multi-az）+ 2 x nat-gw + shared-resources-acctを使用したVPCピアリング

セキュリティ-その他

注1：保存されているすべてのサービスストレージを少なくともAWS暗号化で暗号化することを忘れないでください https://docs.aws.Amazon.com/ aws-technical-content/latest/efs-encrypted-file-systems/encryption-of-data-at-rest.html

注2：AWS Well-Architectedフレームワークの5つの柱- https://aws.Amazon.com/blogs/apn/the -5-pillars-of-the-aws-well-architected-framework /

注3：AWSタグ付け戦略- https://aws.Amazon.com/answers/account-management/aws-tagging-strategies/

注4：AWSシークレットをgitリポジトリに禁止する- https://www.binbash.com.ar/archives/1038

3
Exequiel Barrirero

私のセキュリティハットをオンにして、私はあなたの最適なソリューションは＃1を使用することだと思います。不便な点は確かにありますが、2と3は単一障害点を作成します。単一のAWS許可ユーザーの認証情報が侵害されると、すべての環境が侵害されます。

1
Jesse K