セキュリティ記事タイトルとURLをコピーするこんにちは!イーゴリです。とって、クラウドのセキュリティは最優先事項です。(AWS公式ページ)AWS環境のセキュリティ対策としてAWSサービスを解説するよりも、まずはAWS環境の最適な設計について考える必要があります。Frameworkを考慮しながらの設計を推奨します。Frameworkを全部詳しく読むことをおすすめしますが、この記事では個人的に一番重要だと思う点について記載します。Frameworkとは、クラウドシステムの最適な設計方法を提供するAWSのガイドラインで、6つの柱があります。この記事では基本的に「セキュリティ」の柱を技術的観点から見てみたいと思います。Frameworkの柱:運用上の優秀性セキュリティ信頼性パフォーマンス効率コスト最適化サステナビリティ下記の注意事項があります。Frameworkの全部の項目に沿っていなければいけないというわけではありません!ベストプラクティスを知った上で、ビジネス的な判断で決めないといけません。Frameworkの一部の推奨事項を調整する必要がある場合もあります。予算やリソースの制約から、全てのベストプラクティスを即座に実装することが難しい場合などです。そのようなケースでは、優先順位をつけて実施していくことが重要です。(NIST)のレコメンデーションや個人的な意見もありますので、記載した情報の参考元を項目ごとに記載します。(URL)]のように参考元が記載されていない場合は個人的な意見となりますので、ご注意ください。Organizationsの設計を割愛します。Organizationsの設計については下記の佐竹さんの記事をご参考ください。blog.serverworks.co.jpAWS環境のセキュリティについての解説を3つの記事に分けます。(本番、ステージング、開発、テストなど)ごとにアカウントを分けます。アカウントレベルの分類は、セキュリティ、請求、アクセスのために強力な分離境界を提供するため、強く推奨されます。下記に簡単なイメージ図を作成しました。Management(IAM)の設計IAMポリシーはグループ/ロールに付与する当たり前のことですが、IAMポリシーは、ユーザーではなく、グループやロールに直接アタッチすることをお勧めします。docs.aws.amazon.com例えば、デフォルトでユーザーに管理者アクセス許可を付与するのではなく、必要な権限のみ与えます。Accessなどを付与し、他のサービスにアクセスする権限が必要でなければ、余計な権限を付与するのはNGです。docs.aws.amazon.com例えば、各アカウントでIAMユーザーを作成するのではなく、11つのAWS専用アカウント(踏み台アカウント)でユーザーを作成し、スイッチロールで別のアカウントにアクセスします。Organizationsが必須)。ユーザーのアクセスキーの発行はやめて、IAMロールを使ったほうが安全です。IAMのアクセスキーを利用する場合、広範な権限が漏洩するリスクは減らせるものの、アクセスキーそのものをGitの公開リポジトリなどにアップロードしてしまい、漏洩する可能性があります。IAMロールを使用すると、プログラムにアクセスキーを埋め込む必要がなくなるため、アクセスキーの漏洩リスクを大幅に減らすことができます。長期的なアクセスキーを使用する。リポジトリにアップロードする。docs.aws.amazon.com例えば、私がAWSアカウントを作り、他のメンバーにIAMユーザーを作って最小特権のアクセスを付与した場合、私が自分でルートユーザーを使って日常業務を行うのはNGです。ルートユーザーにアクセスキーを作成しない/削除するAWSのベストプラクティス的にはAWSアカウント用のアクセスキーを作成しないことが推奨されています。ルートユーザーにすでにアクセスキーがある場合、削除することをご検討ください。オペレーションを使用することができます。サービスとリソースへのフルアクセスがあるので、ルートユーザー用のアクセスキーペアを作成しないことを強くお勧めします。docs.aws.amazon.comそもそもルートユーザー以外にもベストプラクティスとして、アクセスキーを使用した認証からIAMロールを使用した認証に切り替えることをお勧めします。「一時的な認証情報を使用する」の項目に記載した通りです。IAMのアクセスキーを利用する場合、広範な権限が漏洩するリスクは減らせるものの、アクセスキーそのものをGitの公開リポジトリなどにアップロードしてしまい、漏洩する可能性があります。IAMロールを使用すると、プログラムにアクセスキーを埋め込む必要がなくなるため、アクセスキーの漏洩リスクを大幅に減らすことができます。長期的なアクセスキーを使用する。リポジトリにアップロードする。(MFA)パスワードだけだとハッキングされやすい時代ですので、多要素認証を設定することが必要です。多要素認証の設定漏れがないように「MFA強制ポリシー」を作って適用すると、ユーザーは自身のアカウントで多要素認証(MFA)を設定しないと何も操作できなくなりますので、有効な方法です。設定方法は下記の記事にありますので、ご参考ください。blog.serverworks.co.jpちなみに、最近は指紋認証も多要素認証として使えるようになりましたので、一時的なパスコードを入力するほかに、指紋認証を設定すると指紋でもログインできます。注意事項:一番安全なMFA方法は、別のデバイスにある(例:携帯)一時コードが発行される、Authenticatorアプリを使うことです!セキュリティを高めたい場合、指紋認証(生体認証)や他の方法は使わないほうが良いと思います。Organizationを使う場合、SCP(サービスコントロールポリシー)でMFA強制ポリシーを適用できます。強力なパスワード強力なパスワードポリシーを設定する必要があります。AWSのパスワードデフォルトのパスワードポリシーは下記となりますが、ポリシー設定の変更については下記の記事をご参考ください。デフォルトのパスワードポリシーでは、次の条件が適用されます。つの文字タイプの組み合わせ使用されているパスワードが緑ゾーンにあるかご確認ください。存在している言葉を使ってしまうと攻撃者がレインボーテーブルを使用し、パスワードをハッキングできる可能性がありますので、注意が必要です。下記の表はhivesystems.comによる調査結果です。パスワードが辞書にある言葉を使用していた、またはウェブサイト間でパスワードを再利用していた場合のパスワードハッキング時間です。(NIST)は、ユーザーからの要請やセキュリティ侵害の明確な証拠がない場合、定期的なパスワード変更を要求しないよう推奨しています。ユーザーが十分に強力なパスワードを何度も作成するのは困難であるためです。DSSなどの基準に準拠する必要性がない場合、最初の段階で一度複雑性の高いパスワードを設定しておくといいかもしれません。「こんな難しいパスワードを覚えられる?」と思う方がいらっしゃると思いますが、すべてのパスワードを覚える必要はありません。いろいろなパスワードマネージャーがありますので、パスワードマネージャーへのアクセスだけきちんと管理しておけば、他のパスワードを覚える必要はなくなります。個人的な意見:パスワードマネージャーなどのパスワードツールを使わないと、使い回さない複雑性の高い複数のパスワードは中々覚えられないと思います。pages.nist.govIAMユーザーを使い回さない常識の話だと思いますが、念の為に記載します。誰が何を行ったか特定できるために、IAMユーザーを使い回してはいけません。Frameworkに明確に記載されていないため、あくまで個人的な意見となりますが、可能であれば、パブリックサブネットにEC2などのAWSで管理されていないリソースを置かないほうが良いと思いますので、AWSマネージドサービスに変えられないか検討する。1EC2を踏み台として使いたい場合、別の安全な方法がありますので、下記の記事をご参考ください。Balancerを配置することを検討してください。内のデータベースクラスターは、インターネットへのルート、またはインターネットからのルートがないサブネットに配置する必要があります。docs.aws.amazon.com例えば、セキュリティグループの場合、下記のような対策が必要だと思います。445)などの高リスクのポートを外に開放してはいけません。WannaCryがSMBの脆弱性を使って、サーバーを感染させたという事例もあったので、どうしてもこのようなポートを開放したい場合、VPN等経由で接続してください。2SSH/RDPポートを開放する場合、ソースを0.0.0.0/0にしてはいけません。VPN経由で接続するかもしくはソースを厳しく制限してください。APIへの呼び出しを行うために公開APIエンドポイントを利用します。Cloud(VPC)内部で動作するサービスは、VPCエンドポイントを通じてAWSリソースと安全に通信することが可能です。DynamoDBのようなサービスは、VPCエンドポイントのサポートが提供されており、これによりVPC内のリソースからこれらのサービスへの直接アクセスが容易になります。よって、セキュリティを高めると同時に、ネットワークトラフィックの効率も向上します。イメージ図:下記の記事をご参考ください。PrivateLinkは、AWSサービス、サードパーティのサービス、または他のVPCでホストされる独自のサービスに安全にアクセスするための推奨される方法です。このサービスを使用すると、すべてのネットワークトラフィックがAWSのグローバルバックボーン内に留まり、インターネットを介して外部に流れ出ることはありません。Firewallを検討してください。クォータについては最新情報をご参照ください。ポリシーあたりのステートレスルール)下記の日高さんの記事もご参考ください。blog.serverworks.co.jpセキュリティグループ内の高リスクのポートを閉じる上記に書いた通り、セキュリティグループ内のリスクの高いポートへの無制限アクセスを許可しないでください。デフォルトのセキュリティグループではインバウンドトラフィックまたはアウトバウンドトラフィックは削除したほうが良いです。削除された項目ですが、個人的には重要な項目だと思いますので、紹介します。意図のあるケースではない限り、アタッチされていない(使われていない)セキュリティグループを削除してください。「launch-wizard-XX」のセキュリティグループを削除することが重要です。間違ってアタッチしてしまうと、大事故に繋がる可能性がありますので、ご注意ください。このコントロールを削除しました。にアタッチされている場合に、合格の検出結果を生成します。特定のユースケースでは、セキュリティグループがアタッチされていなくてもセキュリティ上のリスクはありません。使用すると、セキュリティグループをモニタリングできます。各リージョンごとにデフォルトのVPCが1つありますので、ネットワークの攻撃面を減少させるために、デフォルトVPCは削除したほうがよいと個人的には思います。Frameworkの通り設計することが目的なので、データの暗号化を行います。下記の記事でKMSの使用についても説明しましたので、こちらでは割愛させてください。保管中に暗号化を適用するデータを保存する唯一の方法は、暗号化を使用することだということを確実にする必要があります。サービスとシームレスに統合します。アップロードされるすべての新しいオブジェクトは、追加費用なしで、パフォーマンスに影響を与えずに自動的に暗号化されます。ボリュームを暗号化形式で作成することを指定します。提供するデフォルトキーを使用するか、作成したキーを使用するかを選択できます。blog.serverworks.co.jpRDS:RDSの暗号化を設定する各サービスの暗号化についてセキュリティガイドをご参考ください。伝送中のデータの暗号化パブリック向けリソースとの間で暗号化されているトラフィックのみ許可する必要があります。Webの場合、HTTP(80ポート)ではなく、HTTPS(443ポート)を使いましょう。SSL/TLSは使わないでください。docs.aws.amazon.comELB、S3など:上記に書いた通り、HTTPS(443ポート)を使用する。使用すると、潜在的な攻撃者が中間者攻撃または同様の攻撃を使用してネットワークトラフィックを盗聴または操作することを防止できます。EBS:ボリュームを暗号化するとEC2ーEBS間の通信も暗号化されます。RDS:デフォルトで認証機関が設定されています。選択肢から別のサーバー証明書を選ぶことができます。必要に応じて各サービスごとにログを収集します。サービスとアプリケーションのログ記録を設定することは重要ですが、各サービスのログの何を収集できる/できないかを事前に把握することはもっとも重要です。VPNのログ収集をオンにして、誰がアクセスできたか/できなかったか(トラブルシューティングや不正アクセス調査など)のためにログを収集する予定があって、ログを収集したとします。エンドポイントの認証失敗の数はありますが、失敗ログの詳細はありませんので、ご注意ください。ログに関してもっともやってはいけない注意点:1ログが誰でも見られる状態にしておくこと2ログを永久保存、またはすぐに削除される設定にしておくこと3ログを目的なしで収集すること上記の場合、意味のないログを集めてしまい、意味のない課金(Cloudwatch/S3料金など)が発生します。ログを集めてこのログで何をするかという定義(例:不正アクセス調査のため、◯◯のトラブルシューティングのためなど)が必要だと思います。一般的なアンチパターンについては下記(SEC04-BP01)の項目を御覧ください。高docs.aws.amazon.comちなみに、弊社がサバソック(マネージドセキュリティサービス)というサービスを開始したので、興味がありましたら、是非ご検討ください。次の記事:blog.serverworks.co.jp以上、御一読ありがとうございました。2009-引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。