AWSセキュリティのベストプラクティス

“AWS Security Best Practices” January 31, 2023 by Alex Vakulov より

AWSセキュリティ ― 7つのシンプルなルール

AWSインフラストラクチャのセキュリティは、とどのつまり、あなたにかかっていています。クラウドサービス・プロバイダーの最大手AWSは、そのクラウド環境を安全に保つために巨額の投資をしています。それでもAWSのセキュリティは、とりわけIDとアクセスの管理に関しては、顧客の手に委ねられているのです。

このブログでは、AWSセキュリティを向上させて、望ましくないインシデントが起こる危険性を下げるための、7つのシンプルなルールについてお話しします。また、これらルールは御社のAWSインフラストラクチャーの最適化とメンテナンスの工程効率をさらに促進する効果的な道への指針ともなるでしょう。

AWSインフラストラクチャでの作業の際、セキュリティ・インシデントを引き起こす原因としてよくあるのは、次のようなものです。

インフラストラクチャのメンテナンスとサポートに関連するミス（リソースの削除、誤った修正または構成）
アプリケーション作成の際のミス（ハードコードされた構成、正しいエラー対応ができない、など）
生来の脆弱性を狙ったアプリケーションのハッキングとインフラストラクチャへの攻撃

よくあることですが、クラウドを悪用した複数のインシデントは同時、または連続して発生します。インフラストラクチャーまたはアプリケーションの中で変更するのと同時に、進行中の攻撃をかわし、システムを良好な状態に復元するのは非常に難しいということがお判りでしょう。

AWSインフラストラクチャーのセキュリティ侵害の例

ある晴れた日、大企業のバックエンドでモバイルアプリケーションの更新に携わっているシステムオペレーターが、メインのRoute53のHosted Zoneを誤って削除してしまいました。その結果、インストールされていた数百万というアプリケーションが、バックエンドと交信できなくなります。DNS（Dynamic Name Service）のために残されたTTL（Time to Live、生存時間）は、24時間と設定されており、ハードコード化されているためにアプリケーションの構成の更新はできません。万策尽きた瞬間でした。

こうした問題に関するニュースは、インターネットでまたたく間に拡散され、プロのハッカー集団の注意を引きます。犯罪者集団はすぐに、構成不備になったこの会社のリソースを攻撃しはじめます。結果的にうまくいった攻撃もいくつかありました。

こうした攻撃の1つである昔ながらのSQLインジェクション攻撃が、とある有名なハッカー集団によって実行されました。彼らはすぐに、このニュースをダークウェブのフォーラムで流して弱点を公開しました。

まもなく、別の誰かがモバイルアプリケーションのコードを調べて、管理者権限を持つユーザのアクセス鍵のIDと秘密のアクセス鍵を発見しました。これがどれほど深刻なことで、アプリケーションがどれだけ脆弱になってしまったかは言うまでもありません。

幸い、この時点で既にサポートチームが警告を受けていました。彼らは問題を解決して、攻撃経路を速やかに排除しました。しかし、モバイルアプリケーションはいくつかのバックエンドサービスと通信不能になりました。このアプリケーションのメインのAWS IAM ユーザが侵害されたためです。

当然、この事件の後は、こうした問題をできる限り速やかになくし、今後同様のインシデントが起こらないようにするための戦略について、人々は考え始めることになります。

AWSインフラストラクチャのセキュリティ強化アルゴリズム

自社で利用しているAWSインフラストラクチャを積極的に保護して問題が本格化する前に、その芽を摘んでしまうため、次のようなAWSのセキュリティ強化アルゴリズムを提案します。この「アルゴリズム」は、シンプルであり、比較的すぐに実践できる7つのステップで構成されています。

リソースをチェックしてタグをつける
IAMポリシとパーミッションをチェックする
ログ記録と監視機能を有効にする
セキュリティ評価を実施する
AWSセキュリティの脆弱性とその他のセキュリティリスクを軽減する
データベースの現況をチェックする
障害時復旧（DR）の手順をチェックする

では、それぞれのステップを詳しく見ていきましょう。

1) リソースをチェックしてタグをつける

読者の中には、このような難しい状況で、なぜリソースの検証とタグ付けが真っ先に来るのかと疑問に思う方もいるでしょう。実際、多くの組織にはいまだに、体系的なリソースタグ付けの体系がありません。下のような名称のついたリソースに遭遇することもあるかもしれません。

DO_NOT_DELETE_UNTIL_12/02

具体的にどんなリソースを所有しているのか、なぜそれが必要なのか、それがどれだけ重要なのかを知らなければ、脆弱性の優先順位をつけたり、アクセス権限を設定したり、インシデントの解決手順を作成したりすることは不可能です。ログを読むことも非常に難しくなります。

多くの場合にうまくいく、簡単なリソースタグ付け体系を以下に例示します。

リソース名の形式：uid_function_system
リソースの所有者（部署や担当者）
このリソースが属する環境
このリソースの重要度
この特定のリソースに適用すべきDR手順（バックアップ、自動拡張化、複製など）

異なるAWSリソースグループへのタグ付けは別の形で行なわれます。詳細は以下を参照してみてください。

タグ付け体系を適用して、全てのリソースがタグ付けされた後は、Lucidchart、Hava、Draw.ioなど、さまざまなツールを用いたリバースエンジニアリングを行なったり、アーキテクチャのダイヤグラムを生成したりすることができます。

2) IAMポリシとパーミッションをチェックする

IAMポリシ、パーミッション、権限付与などをチェックすることの重要性は、いくら強調してもし過ぎることはありません。過去にあった実際の不正の例では、最初のインシデントはある一人のエンジニアの過ちから起こり、彼の記憶頼りでリソースが復元されてしまったことによるものでした。適正なアクセス権限ポリシがなければ、さらにプロセスや権限を持った担当者に負担をかけることになります。また保守担当者のミスのために、システムのハッキングや中断が発生する危険も大きくなります。

当然、管理者権限を持ったユーザーがアプリケーションコードで「ハードコード化」されていれば、これによる開発者の作業はより複雑になり、余計なリスクが発生します。

AWSリソースのアクセスポリシーのチェックや調整は以下のような手順で行ないます。

リソースのタグ付けの結果に基づき、アーキテクチャのダイヤグラムの助けを借りて、重要なリソースを文書化する。
重要なリソースそれぞれについて、危険性がある行為のリストをまとめる。たとえば、次のような行為。
- 演算リソース（RDS、EC2、RedShift、ElasticCache）の削除
- その他のリソース（DynamoDB tables、S3 buckets、SNS topics、SQS queues、SES lists、VPN Gateways、Lambda functions、VPC Routes）の削除
- ポリシーの変更（Bucketポリシー、IAM Policies、Security Groupsルール、NACLルール）
危険な可能性のある行為が複数関係する場合は、通常業務用に作成されてテストされたポリシーと、利用されたことのないポリシーとを分ける。リソースのリストを限定することもできる（Condition：Tag）。また、MFAコードを入力して、通常のワークフローには含まれていないか、もともと極秘である、危険な可能性のある行為を実行することもできる。
危険な可能性がある行為を実行するには、特別な役割が常に作成されている必要がある。任務の切り分けと特権の切り分けを実施すると、1つのアカウントにあまりに大きな力を集中させずにすむ。ユーザまたはユーザグループに対してAssume Role Policyを作成すると、その役割をIAMユーザに適用することができる。
役割とポリシーが作成され、割り当てられた後で、そうした役割が適用されるかどうかをテストしてから、危険な可能性のある行為の実行を規制したい場合にアクセスポリシーを制限する。

適切な範囲のAWSアクセスに関する詳細情報は、以下の文書で読めます。

IAM roles for Amazon EC2
Secure Token Service
AWS Cognito モバイルアプリのユーザーの認証と承認について
MFA 保護 API アクセスの設定

AWS、AzureのID、アクセス、権限付与、監査の管理の簡略化、および、BeyondTrustでできるその他のことについては、こちらをご覧ください。

3) ログ記録と監視機能を有効にする

すべてのリソースがわかり、アクセス権限が正しく構成されたら、ログ記録と監視機能に進みます。これらのプロセスはシステム運用を専門にする人にとっては不可欠です。多くのツールで、正しい指標とログ記録を集め、その分析に正確に反映させることができます。

この話題に特化した投稿や著作は数多くあります。AWSに備わっている既存のログ記録と監査サービスを使って何ができるかについて、以下に簡単にまとめました。

ログ記録

AWSには、さまざまな種類のログを収集するためのツールがたくさんあります。まず、AWS APIに関連したユーザとアプリケーション／スクリプトの行為のログ記録に注目する必要があります。ベストプラクティスとしては、この目的のために常にAmazon CloudTrailを使うべきです。

AWS環境では、ログ記録を1年間保有しなければなりません（これは長い期間ですし、オフロードされた場合には、これだけの量に対する安全なストレージ容量を確保しておかなければなりません）。AWS CloudTrailを使って取得したデータは、ユーザーとアプリケーションがAWSインフラストラクチャとどうやり取りしているかを分析する最適な資料となります。

次に、さまざまなツールを使ってCloudTrailを分析することができます。最もよく話に出てくるのが、Cloud Watch Logsについてです。サードパーティのアプリケーションにも、CloudTrailのログを分析できるものはたくさんあります。リストはこちらです。

ほかにも、以下のような有用なログのソースがあります。

Amazon CloudWatch Logsは、AWSログの収集と分析に関する基本的な機能です。ただし、このログをパースするには正規表現を使わなければならず、クエリが複雑な場合は面倒なこともあります。

ほかの手軽な機能はSNSの統合で、特定の問題が発生した場合にアラートを生成して送信する機能は、攻撃や動作異常を特定するのに役立ちます。

ログの収集と分析に関してもっと一般的な別の手段は、ELK（ElasticSearch＼Logstash＼Kibana）またはそれに類するもので、LogstashをCloudWatch Logsに置き換えてAmazon Elasticsearchサービスを使うことも、これに含まれます。このような方法を使えば、ログの分析手順をカスタマイズでき、同時にリソースの割り当てと管理に集中せずにすみます。

監視

Amazon CloudWatchは、監視に関する固有の主要なAWSソリューションです。CloudWatchのおかげで、AWSサービスやそのプラットフォームでホストされているほかのソリューションの監視の機会が豊かになります。このツールにはあらかじめ定義ずみの指標がたくさんあり、リソースの監視を早く効率的に設定することができます。さらに、CloudWatchによってユーザーは、アプリケーション監視やクラウドインフラストラクチャのサポートといったプロセスを統一するため、固有の指標を作成したり利用したりすることができます。もちろん、サードパーティのソリューションを実装して、特定の使用事例やハイブリッドのアプリケーションの監視に拡張することもできます。

4) AWSセキュリティ評価を実施する

セキュリティスキャンは重要なステップで、全てのリソースがわかり、文書化され、アクセス権限が割り当てられ、全ての監視とログ記録のツールがテストと本番のために構成された後で実行するのが最適です。これによって、スキャン結果を正しく評価し、セキュリティの緩和や改善が必要なアプリケーションとインフラストラクチャの具体的な機能を特定することができます。

覚えておくべき重要な点は、セキュリティ評価を開始する際、予定されている動作をAWSに通知しなければならないということです。これは、その評価が攻撃ではなく正当なセキュリティリスク評価であることをAWSに知らせるためです。ただし、AWSによって検証を受けたツールを使い、スキャンの許可を得ていれば、通知の必要はありませんが、自社ツールに基づいたアラートを避けるため、変更制御でその動作のログを記録する必要はあります。

AWSセキュリティ評価には、以下のような基本的なステップが入っていることがあります。

ASVスキャン（VPCとネットワーク）、PCI Security Standards Councilの認定を受けたプロバイダーを使うことができます。
Amazon Inspectorまたはサードパーティのツールを使った脆弱性スキャン。
侵入テスト（必要な場合または規制団体から要請がある場合。たとえば、PCI DSSの要件など）
Cloud Workload Protection Platform（CWPP）を使った脆弱性のサイドスキャンと攻撃評価

5) AWSセキュリティの脆弱性とその他のセキュリティリスクを軽減する

AWSセキュリティのスキャン結果に基づいて、認識されたリスクや脆弱性、構成不備などに対処するステップに進む必要があります。AWSを保護するためのステップには、以下のようなものがあります。

可能な場合はゼロトラストの制御を導入して、安全なAWSインフラストラクチャへのアクセスを確保する
トラフィックのフィルタリング規則（Security GroupsやNetwork Access Control Lists）を訂正したり更新したりする
Web Application Firewallを導入して自社のアプリケーションと統合する
ソフトウェアとオペレーティングシステムに公開されたセキュリティパッチを当てて更新する
サードパーティのソフトウェア(データベース、アプリケーションサーバ、サーブレットコンテナなど)にアクセスするのに使われるパスワードに強力なパスワードポリシーを適用する
認証および承認の手続きを変更する（例えば、IAM User Credentialsからワンタイムトークンに切り替えるなど）
特権アクセス管理（PAM）を導入して、AWSの秘密情報とアカウントを登録・管理できるようにし、最小権限の原則が幅広く、しかも詳細に適用されるようにする
オペレーティングシステム、構成ファイル、サードパーティのアプリケーションなどのレベルで完全な制御を行なえるようにする（例えばOSSECの利用など）

もちろん、上記のステップは、AWSインフラストラクチャを強化し、堅牢なセキュリティを確保するために可能であり、そして多くの場合は必要である制御のほんの一部に過ぎません。理想を言えば、組織がリリース手順の中に情報セキュリティ評価を組み込み、ワークロードと製品が攻撃に対して脆弱にならないよう保つため、この手順を定期的に実行することが望ましいでしょう。

AWS環境へのゼロトラストの導入について、詳細はこちらをご覧ください。

6) データベースの現況をチェックする

ほとんどの情報システムは、構成済みと半構成済みのデータをデータベースに保管しています。ですから、深刻なインシデントの影響や危険性を低く抑えるために最も重要なのは、データベースレベルで障害時復旧機能を備えておくことです。堅牢化やセキュリティに加えて、これを考慮しておいたほうがいいでしょう。

このステップでは、目標復旧地点と目標復旧時間のようなことを考慮する必要があります。さらに、複製ができ、さまざまな可用性オプションがあるからといって、バックアップを取る必要がないわけではありません。RDBMSのみならず、さまざまなNoSQLデータベースに関しても同じことが言えます。

従って、データベースの取扱いに際しては、以下のことがお勧めです。

バックアップの使用可否と、RPOとRTPに基づいて自動的にそれを作成する手順についてチェックする
データベースの使用に関する詳細をチェックする。たとえば、重要な情報がキャッシュ(Memcached、Redisなど)に保管されているか／検索エンジン（ElasticSearch、Solr）が単一サーバーに保管されているか、あるいは、ETLの手順をマスターデータベースで開始するのか、など。
データベースのインストールに関する詳細をチェックし、データの流れを決め（ETLの手順、特殊なアプリケーションを使うことも含め）、こうしたコンポーネント用にHAとDRの手順を導入する必要があるか、あるいは導入できるかを判断する
可能ならば、アプリケーションやユーザが使うデータベースのアクセスパラメータを「循環」させる
固有のツールかサードパーティのSIEMを使い、データベースに特化した監視とログ記録の機能を準備しておく