2&>1

AWSとかGCPとかGolangとかとか

これから社用AWSアカウントを作る人がちょっと気をつけること

対象:これから初めてAWSコンソールを触るような人向けです。

アカウントの分け方

アカウントを作るときはメールアドレスとクレジットカード登録が必要になります。

個人で作る場合はそのまま自分のもので良いですが社用となるとそうも行きません。

作成する環境には「本番」と「検証」の最低2つはあるかと思います。

これが同じアカウント内にあるとリソース増えるごとに煩雑になり事故に繋がります。(リソース名だけでは人はミスをするのです)

なのでこれはアカウント自体を分けて置くと今触っている環境がわかりやすく事故防止に繋がります。

このまま2つのアカウントを運用してもできなくはないですが、今後3つ,4つと増えてくるとアカウント管理に疲弊する状態となります。

そのため最初から「AWS Organizations」とゆうサービスを使ってアカウントを作成します。

これは複数の AWS アカウントを統合して管理するサービスになります。

  • 新規アカウント作成

  • アカウントの階層的なグループ化

  • 各アカウントのAPIへのアクセス制御(root含む)

  • 一括請求(各アカウントへの請求額もわかる)

このようなことができるので親アカウントからツリー状に子アカウントを管理することができます。

f:id:piyojir0:20191217105240j:plain

これにより各アカウントグループOU(Organizational Unit)に対してポリシーを設定できアクセス制御を行えます。

また後述のセキュリティ設定に関わりますが、リソースログやコンソールへのアクセスログなんかも収集できるのでそういった機密情報にあたるログをほいほいと触れる状態は好ましくありません。

そのためadminOUにログ管理用のアカウントを準備して、そのアカウントでログ管理します。もちろんアクセス権限も他アカウントより厳重にします。

もう少し踏みこむとすべての人は「Custodianアカウント」からその他のアカウントへSwitchRoleという方法でログインするとパスワード管理など不要になるので効率上がります。

が、最初の段階では各アカウントに対してパスワードログインで良いでしょう。

のちのち理解が深まったのち設定すれば良いかと思います。

アカウントまとめ

  • AWS Organizationsを使う

  • 用途別にアカウントを分ける

  • 親アカウントがとても重要

こちらのブログが踏み込んだ内容となります

AWS Organizationsによるマルチアカウント戦略とその実装 - クラウドワークス エンジニアブログ

セキュリティの設定

AWSではユーザーが守るものとAWS側が守るものと明確に分けられています。

f:id:piyojir0:20191217111953j:plain

上記のように自分のものは自分で守りましょう。ただし任せれる部分は丸投げしましょうがAWSになります。

GCP、AZureなんかもそうです。

セキュリティといってもその範囲はとても広く深く一番注意すべき内容です。

ここではまずはこれだけっってものに限定して記述します。

I AM

アカウント管理を行うサービスです。

各アカウントに対して権限やログイン方法を設定できます。

前提として共通アカウントは基本作らないようにしましょう

これはなにか問題が起こったときにログから担当者が把握できなくなるからです。

ログイン方法は基本「メールアドレスとパスワード」になります。

それプラスMFA認証も追加しましょう。これはスマホ端末と連携して認証コードも入力させる方法です。

各アカウントに割り付ける権限は「最小権限」を意識しましょう。

例えば、EC2の作成・削除しか扱わないのにIAM編集権限も与えるなど、不要権限をつけないということです。

CloudTrail

APIのログを保存するサービス。

問答無用で有効化。

AWS Config

リソースの変更(コンソール操作など)ログを保存するサービス。

問答無用で有効化。

GuardDuty

機械学習、異常検出、および統合された脅威インテリジェンスを使用することで、潜在的な脅威を識別して通知してくれるサービス。

問答無用で有効化。

AWS Shild

AWSリソースに対するDDosなどL3/L4レイヤーの攻撃を自動で防いでくれる。

無料で使える上に、有料版にするとL7レイヤーまでしてくれるありがたいやつ。

無料版はデフォルト有効なので問答無用。

VPC

セキュリティーグループとネットワークアクセスコントロール通信制御。

iptablesのようなもの)

基本はセキュリティーグループで入ってくる通信を制御(IPとPORT)

各リソースごとにセキュリティーグループを分けられる。

ネットワークアクセスコントロールはサブネット全体に適応されるので一括で制御する必要があるようなものに限定する(inとoutを別々で設定する必要あり)

セキュリティまとめ

  • I AMはMFA認証と最小権限

  • CloudTrail & Config & GuardDutyはすぐ有効化

  • VPCセキュリティーグループで通信制

こちらの資料がとてもよくまとまってます。

AWSでのセキュリティ対策全部盛り[初級から中級まで] - Speaker Deck

ネットワークサブネットの決め方

ネットワークサブネットとはEC2などサーバリソースに割り当てるローカルアドレスになります。

注意すべき点は一度サブネットを作成したら拡張しにくいということです。

(2つ目のサブネットを追加というのはできます)

なぜやりにくいかというと他サブネットとVPNピアリングなどする場合サブネットが重ならない必要があります。

そういった全体設計とおこなった上で各サブネットレンジを決めないと修正できない問題となるのである意味一番重要なポイントになります。

なにはなくとも全体設計重要

基本構成は以下 f:id:piyojir0:20191217125358p:plain

publicはインターネットからアクセスできる

privateはインターネットからアクセスできない

1と2でそれぞれアベイラビリティーゾーンを分けている

WEBサーバは外部アクセスがあるのでpublic,DBはインターネットからアクセスしないのでprivateという感じ。

それぞれにローカルIPレンジを割り当てましょう。指定範囲は以下範囲内が推奨

10.0.0.0 - 10.255.255.255 (10/8 プレフィックス)

172.16.0.0 - 172.31.255.255 (172.16/12 プレフィックス)

192.168.0.0 - 192.168.255.255 (192.168/16 プレフィックス)

広めに設定することが重要です。理由は以下

  • ロードバランサーを設置すると8IP以上必要

  • サブネットの先頭と最後の5IPは使用できない

  • スケールやlamdbaでもIP消費

ネットワークサブネットまとめ

  • 全体設計大事

  • 広めに設計

  • 全体設計大事!

こちらがよいまとめ

Amazon VPC設計時に気をつけたい基本の5のこと | Developers.IO

公式もよい

https://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/VPC_Subnets.html

バックアップ設定

EC2やRDS、EFSなどはバックアップできます。

適度なタイミングでバックアップしておくことで万が一のとき生きれます。

RDSは構築時にバックアップ設定できるのでそこで7世代とかしとけば問題ないかと。

EC2などは別でバックアップ設定が必要です。

こういうの参照

AWS Backup – バックアップの自動化と集中管理 | Amazon Web Services ブログ

バックアップまとめ

  • 忘れず設定

  • 保存世代数はお金と相談

まとめ

自分への振り返りも含めてまとめてみました。

最初の取っ掛かりは1インスタンスからでよいのでまずは作ってみることが成長です(自戒