COLUMN

1.前置き〜AWSは安全？〜

みなさんはAWSやクラウドを利用する際のセキュリティに対してどんな印象をもっていますか？

「なんだかよくわからないけど不安だ」と感じている方、いい感覚です。初めて扱う技術を怖く感じることは正常な感覚です。しかし、過剰に怖がりすぎるのは違いますね。

逆に「AWSやクラウドは安全だからセキュリティを気にせず使って大丈夫だ」と感じた方は少し危険かもしれません。自らの正確な知識と正しい根拠がないまま勝手に安全だと信じることは正常な感覚ではありません。

いずれの場合も、AWSやクラウドについてこれから学習していく場合、それが未知のものであるため適切に怖がる必要があるでしょう。そしてAWSのセキュリティについて適切に理解することで、正しく安全に活用していくことができます。知ることがセキュリティの第一歩です。そのため前置きも含めてやや長い記事ですが、読み飛ばさず順番に理解を深めてください。

1-1.本記事の対象読者

この記事は主に以下のような方を対象としています。

• これからAWSを触り始めるエンジニア
• 新社会人としてAWSを扱い始める方
• 新しくAWSを扱うプロジェクトに参加した方

その中でも特に、一般的なAWS利用者を想定して説明していきます。レベル感としては、IT技術の基礎については履修されている想定とし、IT技術全般の話はある程度割愛して説明しますので、気になる用語が出てきた場合には別途調べてください。

また、これからAWSの管理者になる方は、後日管理者編を執筆しますので、こちらの記事と合わせてそちらも参照してください。

2.セキュリティとは？クラウドとは？

AWSのセキュリティを理解していくためには、セキュリティ自体、クラウド自体を理解していく必要があります。まずはここから始めましょう。

2-1.なぜセキュリティが必要なのか

そもそもなぜセキュリティが必要なのでしょうか？セキュリティとはなんでしょうか？

一般的なセキュリティとは、なにかを「守る」ことで安全を確保することです。この言葉はイメージしやすいですよね。

例えばみなさんの自宅の玄関扉には鍵がかかっていて、これがセキュリティとして機能して自宅を「守る」働きをしています。鍵の必要性については説明するまでもないでしょう。正確には自宅そのものだけでなく、自宅にある様々なものも守っていますよね。例えば自宅に住む人の命も守っていますし、家財や現金なんかも守る対象です。鍵があることで安全に過ごすことができますね。

ITの現場で使う「セキュリティ」という言葉は正確に表現すると「情報セキュリティ(Information Security)」のことを指します。ITにより情報社会となった現代では、情報を扱うことは企業にとって当たり前です。社員はPCを使って様々なシステムを利用し業務を行い、企業の重要なデータはサーバーストレージやデータベース等に保管され経営の意思決定に活用されます。これらのシステムやデータを守らなければ、もはやビジネスが停止するレベルまでITはなくてはならないものになっています。つまり企業にとっての情報セキュリティは、「ビジネスのために」これらの重要なシステムやデータを守ることになります。企業の情報を守り、安全にビジネスを行うためにはセキュリティが必要です。

2-2.必要なセキュリティとはなにか

セキュリティが必要であることはわかりましたが、セキュリティにもいろんな種類があります。

先程の例えの続きですが、すべての人にとって鍵は間違いなく必要とわかりますが、自宅に対するセキュリティは鍵だけではありません。監視カメラはどうでしょうか？一部の家庭にはあるかもしれませんが、必ずしも必要ではないかもしれません。監視カメラを設置し維持する費用がかかりますよね。ホームセキュリティの警備会社は必要でしょうか？監視カメラよりも更に費用がかかります。普通はいらないかもしれませんが、もしあなたが著名人なら必要と感じるかもしれません。なぜでしょうか？

ここはすごく大事なポイントです。

例えば著名人であれば自宅に価値の高いものが多く存在する場合もあるでしょう。一般家庭と比較すると、それはよりコストをかけても守りたいと判断することもあるでしょう。あるいは著名人であるため、押しかける人が多かったり、犯罪者に狙われる可能性もあります。一般家庭と比べてリスクが高いと判断できれば、よりコストをかける必要性がでてきます。

つまり守るものの価値や、守るものが危険にさらされるリスクに応じて、セキュリティにかけるコストが変わるということです。そしてコストには限界がありますから、闇雲にセキュリティを追加してもダメです。コストと守るものの価値のバランスを意識する必要があります。

守るものより高価なセキュリティを導入したら本末転倒ですよね。

企業における情報セキュリティでは、安全にビジネスを行うためのものですから、当然ビジネスでの収益を無視したセキュリティは不適切です。ビジネスで得られる収益と守るべきシステムやデータの価値のバランスを意識したセキュリティが必要です。もしそれらの価値に対して収益が足りないなら、企業としてそのビジネスモデル自体を見直すべきでしょう。リスクが高いビジネスをしていることになります。

2-3.なぜクラウドを使うのか

AWSはクラウドサービスの1つです。現代では企業は様々なクラウドを利用していますがそれはなぜでしょうか？そもそもクラウドとはなんでしょうか？

クラウドの定義は様々ありますが、概ね共通して言える特徴は「インターネットを介して必要な分だけ利用できるインフラ・プラットフォーム・サービスを提供している」ことです。

初めてクラウドに触れる方にとってはこの概念が分かりづらいと思うので詳しく説明します。

クラウドを理解するためには、この対比として使われるオンプレミスという言葉を理解する必要があります。オンプレミスとは概ね自社で、ITに必要な物理的な場所(データセンター等)を確保し、サーバーやネットワーク機器などを調達し、その上にOS/ミドルウェア/アプリケーションを構築し、システムを動かす形態を指します。いろんな要素を上げましたが、つまりオンプレミスは考えることややることが多いので時間と手間がかかります。でも昔のITは選択肢がないため仕方なくみんなこの方法で情報システムを構築していました。特にシステムを動かすための環境をインフラ(インフラストラクチャ)と呼びますが、新しい情報システムの構築を行う前にインフラの準備で3ヶ月かかったりしていましたし、システムの需要が増えてインフラを増築したいと考えてもまた3ヶ月時間がかかるなどが当たり前でした。通常のインフラ機器は減価償却が5年のため、減らすことも容易ではないため調達する機器の量の見積もりにも時間をかけます。それでも予測が外れたら無駄なコストになります。

クラウドが誕生したことで企業に選択肢が増えました。インターネットを経由して手軽に調達できるインフラや、アプリケーションを構築しなくてもそのまま利用できるサービスがあり、これらが使った分だけの費用で済むことは、従来のオンプレミスと比べて破壊的な違いであり、物事の速度が桁違いです。これまで調達に3ヶ月かかったインフラは5分で利用開始できます。要らなくなったらすぐに破棄でき余計なコストがかかりませんし、調達の判断に時間をかける必要がなくなります。オンプレミス時代にかけていた時間は本来のビジネスのために使用できます。

つまり、クラウドはビジネスを素早く・コスト効率良く展開するために利用します。

クラウドのメリットをより詳しく理解したい方はAWSのクラウドが選ばれる10の理由もぜひご覧ください。わかりやすい図で解説されています。

3.セキュリティとAWSの基礎

セキュリティとクラウドについて理解が深まったところで、基礎的な知識を身に着けていきましょう。

3-1.情報セキュリティの3要素

セキュリティが必要なことは理解していただいたと思いますが、具体的にどのようなことを考えていけばいいでしょうか？「このセキュリティは必要そうかな？」と個人の感覚で考えるのは難しいですよね。

情報セキュリティでは一般的な定義として情報セキュリティの3要素と呼ばれるものが存在します。

情報セキュリティの3要素は、日本でも広く参照されている「ISMS(情報セキュリティマネジメントシステム)規格」が定義されているISO/IEC 27000ファミリーの国際規格群の中に記載されています。グローバルで広く使われる考え方ですから、まずはここから考えていきましょう。

情報セキュリティの3要素は以下の3つの要素です。

• 機密性(Confidentiality)

  • 情報を許可された人だけが見られるようにすること
  • パスワードを設定したり、データを暗号化したりして、情報を守ること

• 完全性(Integrity)

  • 情報が正しく伝わり、改ざんされていないことを確認すること
  • ウイルスや不正アクセスによる情報の書き換えを防ぐこと

• 可用性(Availability)

  • 必要な時に、情報にすぐにアクセスできるようにしておくこと
  • システムの障害や攻撃で、情報が使えなくならないように対策すること

上記の内容を見てみると、どれも当たり前に必要であると感じられると思います。この3つは情報システムにとって基本的な機能です。ちなみに、情報セキュリティの3要素はそれぞれの英語の頭文字を取ってCIAと呼ばれることがあります。

3-2.情報セキュリティの責任は誰が持つのか

情報セキュリティは簡単なものではありません。情報セキュリティの3要素からやることを考えて、その対策を実行していくのは誰か1人で行えるものではないでしょう。

企業で利用する情報システムに対する情報セキュリティに責任を持つ人物はだれか？答えは簡単です。この情報システムに関わるすべての人が責任を持たなければいけません。例外はありません。

具体的に考えていきましょう。

まず情報システムを構築する人に責任があることは言うまでもありません。

情報システムを使う人にも必要でしょうか？システムにログインするためのIDとパスワードをメモした紙をうっかり社外で落としたらどうでしょうか？社内に閉じておくべき情報の機密性が破られ、第三者に情報が漏洩します。使う人も責任を持ってIDとパスワードを管理する必要があります。

経営者にも責任が必要でしょうか？構築する人に任せるだけでいいですか？もちろんいいはずありません。情報漏洩が発生した場合、最終的な責任は経営者が取ります。

ビジネスに必要な情報システムですから、適切なコストをかけてセキュリティ対策を行わせる必要があります。時間や金銭的なコストが足りなければ、構築する人は適切なレベルのセキュリティを確保できません。すべてのセキュリティ対策を経営者が主導する必要はありませんが、代わりにこれを主導する人を任命すべきです。情報システムに関わる人に対する教育を実施することも指示すべきです。経営者は企業で行われるすべてに最終的な責任を持つことが求められます。

情報システムに関わるすべての人が責任を持つ必要がありますが、それぞれ責任の範囲は違います。責任の押し付け合いをせず、必要な範囲のセキュリティを実施しましょう。

3-3.AWSにおけるセキュリティの責任

組織の中での責任の範囲もそうですが、AWSを利用する場合にはAWSと利用者との間のセキュリティの責任も理解する必要があります。

AWSは責任共有モデルとして以下の図のように、その範囲を理解しやすい形で表現しています。

AWSが提供するクラウド自体のセキュリティはAWSが責任を負います。AWSのサービス自体が動いているデータセンターや物理的なハードウェア、その上に動く各種AWSのサービスそのものなど、インフラの保護を行います。

利用者はその上で、クラウドを使う上でのセキュリティの責任を負います。AWSが提供する各種設定を適切に理解して使い、適切なレベルのセキュリティを保つ必要があります。利用者が任意で選択できる各種AWSのサービスの選択から始まり、OS/ミドルウェア/アプリケーションの設定や維持運用、その上に保存されるデータのセキュリティも利用者の責任です。

こう説明すると考える範囲が広く感じるかもしれませんが、AWSの責任範囲である物理的なインフラストラクチャも、オンプレミスではすべて自分たちの責任範囲でした。例えばデータセンターのセキュリティの人員や設備のコストや、人の物理アクセスの管理もセキュリティの一環です。

データセンター - AWS のデータセンターではAWSが実際にどのような管理を行っているか確認できます。これと同等のセキュリティを自分たちで担保することは大変であると理解できると思います。

3-4.AWSにおける基本的なセキュリティ

AWSは一般的に利用できるITサービスやクラウドと比較しても、特にできることの幅が広いサービスです。例えばAWSではない他のサービスであれば、メールを送るサービスや、データを保管するサービスなど、それぞれ目的に特化したものが考えられるでしょう。しかしAWSはメールを送るAmazon SESや、データの内、オブジェクトを保管するAmazon S3やデータベースとして機能するAmazon RDSなどそれぞれの機能を有するサービスが多数あり、2024年4月時点で200以上のサービスがあります。AWSはこれらのサービスを組み合わせて、様々な目的に合わせたシステムを構築することができます。端的に言えば何でもできるといっても差し支えないでしょう。

この特性は非常にメリットがありますが、何でもできるということは、その分考慮する範囲も広く、責任も伴うということです。AWSの特性からくる、特に考慮しなければならないリスクを2つ挙げます。

1つ目はインターネットを経由して利用するサービスであるため、常に外部にさらされるリスクがあるということです。設定を誤ってしまうと、AWSのアカウント自体や、AWS上に作成したリソースに第三者が侵入できる可能性があります。

2つ目は従量課金であるため、際限なく金銭コストを浪費してしまうリスクがあることです。AWS上で非常によくある事故の例としては、1つ目のリスクが顕在化し第三者がAWSアカウントに侵入した後、大量のサーバーを作成されコインマイニングされます。

いずれもAWSの特性を理解し、適切な管理を行えば十分問題のないレベルのリスクです。むしろ、適切に使用するだけでオンプレミスと比べ物にならないセキュリティとビジネス的なメリットを手にすることができます。リスクを適切に理解すれば、適切な範囲で怖がる(注意する)ことができます。AWS自体のセキュリティは適度にAWSに任せつつ、自分たちのセキュリティは過信せず実施をしていくことが大切です。

この2つのリスクはいずれも、セキュリティの基本であり原理原則の1つであるアクセス制御によってリスクを低減し事故を防止できます。アクセス制御では、正しい人が正しい権限でのみAWSを利用できるよう制御することで、本来利用できない第三者がアクセスできないようコントロールし機密性を保ちます。

アクセス制御を行うことはあたりまえのように感じられるかもしれません。その通りです。あたりまえのことを適切に実行することがセキュリティの基本です。しかし、実行していくには具体的にどのようにしてアクセス制御を実現するのかという知識や経験は必要になりますね。

4.最初に知っておくAWSの安全な使い方

AWS環境におけるアクセス制御は様々あります。これは、AWSが様々なサービスを提供しており、自由度が高いことに起因します。全てのものに対するアクセス制御を知ることは大変なので、ここではAWSを使い始めるときに最初に知っておくべき3つのアクセス制御について説明します。まずこれだけ知っておけば、自信を持って安全にAWSを利用し始められます。

具体的には以下の3つです。

• AWS環境へのIAMによるアクセス制御
• S3に保存されているデータへのアクセス制御
• EC2に対するネットワークのアクセス制御

順番に説明します。

4-1.AWS環境へのIAMによるアクセス制御

これは私の言葉ですが、AWSのセキュリティはIAMに始まりIAMに終わると言っても過言ではないくらい、IAMが大切です。IAMはIdentity and Access Managementのサービスです。AWSアカウント上で操作するIDを司るサービスであり、AWS全体のアクセス制御を行います。

おそらく、AWSの利用者としてみなさんが初めて与えられるAWS上のIDはIAMユーザーでしょう。これを利用して、AWS上で様々な操作を実施します。ぜひこれからIAMを使っていく前に、下記内容を押さえて安全に利用するための知識を身に着けましょう。

4-1-1.AWSアカウントとユーザー

AWSを利用するときの一番大きな概念はAWSアカウントです。「AWSを使いたい！」と思ったときに最初に作成します。AWSアカウントはAWSアカウントIDと呼ばれる12桁の数字で識別します。よくサンプルで999999999999や123456789012等と表現されます。作成したAWSアカウント1つ1つにこのようなAWSアカウントIDが付与され、これらのAWSアカウントは論理的にすべて独立しています。つまり原則としてAWSアカウント間は操作やデータの移動ができません。明示的に許可しない限りはAWSアカウントを超えてのアクセスができないため、AWS上で一番強いアクセスの境界線となります。そのため、現在では1つのシステムやプロダクトごと、環境ごとにAWSアカウントを細かく分割して利用することがベストプラクティスになっています。AWS環境にアクセスして操作するためのユーザーも、基本的にAWSアカウントごと別々に作成します。

4-1-2.AWSを操作する2つのユーザー

AWSを操作するためのユーザーは大きく2種類存在しています。

• ルートユーザー
• IAM(IAMユーザー/IAMロール)

もしあなたが管理者からルートユーザーを渡された場合、今すぐにその使用を停止して管理者にもこの記事を読んでもらいましょう。

■AWSセキュリティの大原則の1つ、ルートユーザーは利用してはいけません

ルートユーザーはAWSアカウントにおける最高の権限を保有し、制限なくすべての機能を利用できます。そのため、普段使いするIDではありません。ルートユーザーは初めてAWSアカウントを作成したときに一緒に作成されるIDで、登録時のメールアドレスとパスワードでログインする方式です。AWSアカウントを作成したら、まず普段利用するためのAdministratorAccess権限を付与したIAMユーザーを作成し、ルートユーザーはMFAを設定した後封印しましょう。

ルートユーザーに関するベストプラクティスはAWSアカウントのルートユーザーのベストプラクティス - AWS Identity and Access Managementにまとまっていますので、ルートユーザーを操作する人は確認してください。

IAMには以下の4つの構成要素があります。

• IAMユーザー
• IAMグループ
• IAMポリシー
• IAMロール

前者3つはよくある概念で比較的わかりやすいです。以下の図で関係性を説明します。

IAMユーザーはAWSを利用するためのIDで利用者を識別し、IAMグループが論理的にIAMユーザーをまとめて管理できます。IAMポリシーがAWSの操作権限を定義し、IAMユーザーやIAMグループにアタッチして権限を付与します。

IAMロールはAWSにおいて特殊な概念です。基本的な役割はIAMユーザーと同じで、IAMロールにもIAMポリシーをアタッチして権限を付与し、操作しているエンティティを識別します。最大の違いはIAMロールは人ではなくAWSリソースが利用します。例えば以下のようになります。

人がS3を操作する場合、S3を操作できる権限を定義したIAMポリシーを用意し、これをIAMユーザーにアタッチして、人がIAMユーザーを使ってS3にアクセスします。

EC2がS3を操作する場合、同じIAMポリシーをIAMロールにアタッチし、このIAMロールをEC2にアタッチし、EC2がIAMロールを使ってS3にアクセスします。

やっていることは一緒で、使うものがIAMユーザーかIAMロールかという違いだけです。実はIAMロールの概念はもう少し複雑ですが、基本はAWSリソースのIDと覚えておけばOKです。

4-1-2.IAMユーザーとAWSの操作方法

IAMユーザーを利用してAWS環境を操作する場合、2つの種類の操作方法があります。

• ユーザーID/パスワードを利用してWebブラウザからAWSマネジメントコンソールにログインして操作
• アクセスキー/シークレットアクセスキーを利用してシェルやプログラムからAWS CLIやSDKで操作

それぞれ操作する場所も違いますし、操作するためのクレデンシャル(パスワードやアクセスキーなどの認証のための情報)も違います。

AWSを初めて触る場合や直感的に理解したい場合も含め、人が操作する場合はほとんどAWSマネジメントコンソールを利用することになります。一方で、AWS CLIやSDKを利用することでプログラムから複雑な処理を素早く正確に実行できるため、本番環境での作業や機械的に大量に処理をしたい場合などではこちらを利用します。2つの操作方法は目的ごとに使い分けます。

IAMユーザーを作成するときや、設定変更でこの2つの操作方法のどちらを使うか・両方使うかを選択できます。

4-1-3.IAM利用時のよくある事故

IAMで一番良く起きる事故は、IAMユーザーのアクセスキー/シークレットアクセスキーをプログラムに直接埋め込み、そのプログラムをGitHubなどパブリックな場所に公開してしまうことです。

その結果、該当IAMユーザーが所属するAWSアカウントが侵害され、大量のコインマイニング用のEC2が作成され、翌月ものすごい額の請求を受けます。私が実際に確認したことがある現場では、誤ってGitHubに公開してから10分後には攻撃が始まった事例があります。詳しくは【実録】アクセスキー流出、攻撃者のとった行動とその対策 | DevelopersIOを御覧ください。

この事故の怖いところは、攻撃者のすべての行動が自動化されていて、機械的にすばやく侵害されることと、金銭的被害が非常に大きいことです。AWSを利用し始める前に、すべてのユーザーがこのリスクを知らなければいけません。

4-1-4.最初に知っておくIAMベストプラクティス

誤ったIAMの使い方による事故を防ぐため、まず以下のIAMベストプラクティスを心に刻んでください。

■アクセスキーをプログラムに直接埋め込んではいけない

これはAWSに関係なく以下の情報セキュリティの原則を具体的にしたものです。

■認証情報をプログラムに直接埋め込んではいけない

認証情報は機密情報でもありますから、この事故はつまり機密情報の漏洩です。機密情報の漏洩の中でも、その情報から派生してAWS環境全体や組織のシステム全体が侵害される可能性がある、2次被害の影響も大きい事故です。

以下のようなプログラムがアンチパターンです。

import boto3

# Pythonにおけるダメな例
access_key = "AKIAIOSFODNN7EXAMPLE"
secret_access_key = "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY"

iam = boto3.client(
       'iam',
       aws_access_key_id=access_key,
       aws_secret_access_key=secret_access_key)
users = iam.list_users()

アクセスキーをプログラムに埋め込まないために以下2つの環境における認証情報の設定方法を知りましょう。

• 利用者のローカル端末でのAWS Config設定
• EC2やLambdaなどでのIAM Role設定

この2つの設定方法は共通して、プログラムが実行される環境から自動で認証情報を取得させます。

利用者が所持するローカル端末では、AWSの認証情報はAWS CLIにて設定を行います。AWS CLIのインストールはインストール手順のユーザーガイドを参考に実施してください。認証情報の設定はシェルからaws configureコマンドで以下のように設定します。

$ aws configure
> AWS Access Key ID [None]: AKIAIOSFODNN7EXAMPLE
> AWS Secret Access Key [None]: wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
> Default region name [None]: ap-northeast-1
> Default output format [None]: json

詳細はAWS CLIの認証情報の設定に関するユーザーガイドを参照してください。

EC2やLambdaなどAWSリソースの実行環境上でプログラムを動かす場合には、該当するAWSリソースにIAM Roleをアタッチすることで設定します。IAMロールのアタッチ方法はIAMロールをEC2インスタンスに設定をしてみた | DevelopersIOを参照してください。ただし、AWSアカウントにおいてIAMの操作権限を持つことは、管理者に近い権限を持つことに等しいため、これからAWSを利用し始める人がこれを実施することはあまり適切ではありません。IAMについて習熟したチームリーダーや管理者などがIAMの管理をすべきです。そういった人に実現したいことを説明し、適切なIAMロールを発行してもらい設定しましょう。

それぞれの環境で適切に認証情報の設定がされていれば、プログラムは以下のようにして認証情報を利用します。

import boto3

# Pythonにおける適切な例
iam = boto3.client('iam')
users = iam.list_users()

認証情報に関する設定をプログラム上では明示的に指定しないことで、環境から自動的に取得します。

他にも利用者が最初に知っておくIAMベストプラクティスには以下があります。

■最小権限の原則を意識する

これはIAMに限らない情報セキュリティの原則です。必要のない権限を与える場合、必要範囲外の操作や閲覧が行われ事故に繋がります。AWSではIAMポリシーによりすべての操作を細かく制御できます。可能な限り権限は絞りましょう。ただし、開発を行う場合など柔軟性が必要な環境もありますので、状況に応じた最小の判断が必要です。これからAWSを触っていくのであれば、「最小権限を意識する」という気持ちがあれば十分です。例えば、各種リソースの読み込みや書き込みを特定して必要なものだけに絞ったり、操作対象のリソースを限定したりしましょう。以下の例はS3バケットの特定バケットの特定パスのみ書き込みを可能にするポリシーの例です。

■IAMユーザーには必ずMFAを設定する

これも非常に多い事故に対する対策です。現代のインターネット経由で利用するサービスは、ID/パスワードだけで保護することはできません。第三者がこれらの組み合わせを試す時間的余裕が十分あり、またよくあるパスワードや漏洩した認証情報が使われればもっと突破される可能性が高まります。

こういった問題に対するため、現代のインターネット経由で利用するサービスは、MFA(多要素認証)を設定することが一般的です。

IAMユーザーでMFAを設定する場合はAWS IAMユーザーのMFAをスマートフォンで設定する方法 | DevelopersIOを参考にしてください。

■IAMユーザーは一意に払い出す

これは厳密には利用者ではなく管理者向けのベストプラクティスですが、1人につきIAMユーザーは1つ払い出される必要があります。IDは識別、つまり誰が操作をしたか・誰がその権限を持つか特定するためのものです。1つのIDが複数人で共用されることは識別を阻害する要因となりアンチパターンです。もし共用のIAMユーザーが払い出された場合、管理者にこの記事を提示してください。

■複数AWSアカウントで一人のIAMユーザーを複数発行しない

現代では1つのプロダクトでも複数のAWSアカウントを利用することはあたり前になっています。しかし、複数のAWSアカウントを操作するために、それぞれのAWSアカウントに対応するIAMユーザーを複数払い出していては、IDの管理が煩雑になります。利用者は1つのIDで複数環境が利用できるようになっているべきです。これはつまり、以下の情報セキュリティの原則に集約されます。

■IDは集約管理する

ID情報を複数のプラットフォームにまたがって個別管理をすることは、組織の情報システム管理が複雑になるアンチパターンです。可能な限りIDは集約管理すべきです。理想としてはMicrosoft Entra IDやOktaなどのIdPに組織のIDを一元的に集約し、これと連携してAWSアカウントを利用できるようにすべきです。いわゆるシングルサインオン(SSO)の実現です。こういったID統制は実現することは容易ではありませんが、組織の情報部門が率先的に取り組む課題です。

上記が難しい場合、まずはAWSのIDだけでも集約するため、AWS上でSSOを実現するIAM Identity Centerを利用するか、Jumpアカウント方式と呼ばれる構成方法でIAMユーザーを1つのAWSアカウントに集約管理し、実際に利用するAWSアカウントのIAMロールにスイッチロールできるよう管理者に整備してもらいましょう。詳細はスイッチロール先の本番・開発アカウントにてIAMロール、ポリシー、パーミッションバウンダリーを作ってみた | DevelopersIOを参照してください。

ちなみに、IAMロールを人が利用する事になり先程の「IAMロールはAWSリソースが利用する」という表現と矛盾するように見えるかもしれませんが、IAMユーザーというAWSリソースがIAMロールを利用しているため問題ありません。

■アクセスキーは極力利用しない

実はローカル端末でアクセスキーを設定して利用する方法は一番最適な方法ではありません。アクセスキーは永続的な認証情報という性質を持ち、期限切れになることはありません。これはつまり、万が一漏洩してしまった場合は永続的に利用されてしまいます。代わりに一時的な認証情報を利用すべきです。AWSにおける利用者のローカル端末で利用できる一時的な認証情報は、IAM Identity CenterなどのSSOの仕組みから払い出すものが活用できます。組織がそのような段階であれば、アクセスキーは撲滅させましょう。

その他IAMのベストプラクティスについてより詳しく知りたい方はIAM でのセキュリティのベストプラクティス - AWS Identity and Access Managementを参照してください。

ちなみにこれはおまけですが、非常に高度なIAMの解説としてAWS入門ブログリレー2024〜AWS IAM編〜 | DevelopersIOもありますのでより深くIAMを探求したくなった方は参照してください。

4-2.S3に保存されているデータへのアクセス制御

Amazon S3はAWS上で利用できる非常にコストパフォーマンスに優れたオブジェクトストレージです。簡単に言うとあらゆるデータを保存する場所です。S3は単に利用者がデータを保存するだけに留まらず、外部共有するためのWebコンテンツなどを配信したり、他のAWSサービスのログデータなどの保管先となったり、データ分析サービスから参照するデータストレージとなったりと、AWSにおける中核であったり、ハブになるサービスです。S3の用語やユースケースなどはAWS入門ブログリレー2024〜Amazon S3編〜 | DevelopersIOも参照してください。

このようにたくさんのデータが集まる特性と、利便性が良い特性が合わさって、S3でもよく事故が発生します。

4-2-1.S3利用時のよくある事故

S3はよく利用者が設定を誤ることで、第三者に機密情報を漏洩してしまいます。S3はデフォルトで情報を外部に公開することはありませんが、Webコンテンツを配信する場合など、外部共有する仕組みが存在します。利用者が誤って機密情報の含まれるS3を公開してしまったり、公開しているS3に誤って機密情報を保存してしまうなどの事故がよく発生します。データに対するアクセス制御も適切に実施しましょう。

4-2-2.S3におけるデータのアクセス制御

S3のデータには以下2種類のアクセス制御が混在しています。

• IAMによるアイデンティティベースアクセス制御
• S3によるリソースベースアクセス制御

アイデンティティベースのアクセス制御は、アイデンティティ、つまりIAMユーザーやIAMロールなどのIDに対して権限を与えて(あるいは与えずに)制御します。これはアイデンティティに対する制御としては適切ですが、データを保管するS3側は、誰であろうと保管するデータの特性に応じて一定のアクセス制御を働かせたくなります。そこで一緒に利用するのがS3側のリソースベースのアクセス制御です。わかりやすいところでいうと、機密情報が保管されているS3では絶対に情報を公開できない設定とすることが可能です。この2つのアクセス制御を両方使います。

S3では一番大きな入れ物の単位をS3バケットと呼び、S3バケットごとにリソースベースのアクセス制御を細かく設定できます。

代表的なアクセス制御は以下2種類があります。

• ブロックパブリックアクセス
• バケットポリシー

ブロックパブリックアクセスはS3の様々なアクセス制御の上から強制的にパブリックアクセス(外部共有)を防止する機能です。公開する必要がないデータを扱う場合には必ず使います。

バケットポリシーは、S3バケットに対する具体的に詳細なアクセス制御を行う設定です。S3バケットのデータを公開するパターンとしては、パブリックに公開するパターンもあれば、特定のAWSアカウントや特定のIAMに限定してアクセスを許可する場合もあります。特に限定したアクセスを行う場合には、必ずバケットポリシーに成熟した人のレビューを受けてください。バケットポリシーは設定を誤ると必要以上にデータを公開してしまう可能性がありますので、慎重に扱いましょう。

4-2-3.最初に知っておくS3ベストプラクティス

S3にあるデータを適切に保護するために、以下のベストプラクティスを心に刻んでください。

■データを分類し適切なアクセス制御を施す

これは情報セキュリティの大原則です。まず、自分たちがどのような情報を扱っているか、これを識別し分類する必要があります。顧客の個人情報やビジネス上重要な機密データを扱っている場合には、まずそれを扱っていることを認識することで、適切にアクセス制御を行うことができます。機密情報を扱うS3バケットは、それが保存されているとわかるように名前を分け、他の情報と混ぜないように気をつけましょう。

■機密情報を扱うAWSアカウントを分割する

S3バケットの分割ももちろんですが、機密情報を扱う場合AWSアカウント自体も可能な限り分割しましょう。AWSで一番大きな分割単位はAWSアカウントになりますので、データを取り扱うAWSアカウント自体を分けることで論理的な境界線を作ることが可能です。

■ブロックパブリックアクセスでS3バケットの公開を防止する

ブロックパブリックアクセスを利用することで、バケットポリシーなどで誤った公開をしてしまった場合でも、それに上書きして強制的に公開を防止することが可能です。公開する情報が含まれていないAWSアカウントやS3バケットの場合はこれを必ず設定しましょう。現在ではデフォルトでこの設定が入っているため、変更しないようにしましょう。

ブロックパブリックアクセスは2種類の設定レベルがあります。

• AWSアカウントレベルのブロックパブリックアクセス
• S3バケットレベルのブロックパブリックアクセス

AWSアカウントレベルのブロックパブリックアクセスは、設定したAWSアカウント全体で適用されます。基本的にこの設定を外す場合、そのアカウントで情報を公開することを意味しますので、用途がない限りこの設定を外さない方が良いでしょう。以下の画面で設定が確認できます。すべて「オン」が基本です。

どうしても外部公開するデータが存在する場合も、そのAWSアカウントのすべてのS3バケットで公開するわけではありません。AWSアカウントレベルのブロックパブリックアクセスを利用できないときには、S3バケットレベルのブロックパブリックアクセスを活用します。これは各S3バケット詳細画面の「アクセス許可」タブにて設定できます。同じくすべて「オン」にしましょう。

ブロックパブリックアクセスには4つの設定値がありますが、基本的には全部オンか全部オフで使うと考えて大丈夫です。

■バケットポリシーで最小権限を実現する

バケットポリシーは「誰が」「どのように」S3バケットのデータにアクセスしてよいか(ダメか)を詳細に制御するポリシーです。S3バケット単位で設定し、該当するAWSアカウント内部のエンティティや、別AWSアカウントからのクロスアクセス、パブリックなアクセスもここで制御します。デフォルトではバケットポリシーは空で、この状態ではAWSアカウント内部のエンティティからのアクセスは許可され、それ以外の外部からのアクセスは許可されていない状態です。内部向けのデータでも機密情報で限られた人やシステムしか閲覧してはいけない場合には、該当するエンティティのみアクセスを許可するようにバケットポリシーを設定しましょう。

特によくあるバケットポリシーの構成例は、Amazon CloudFrontと連携してデータをパブリックに配信する場合です。この場合に限り、ブロックパブリックアクセスを設定していても配信ができるため、HTML/CSS/JavaScript/画像や動画などのコンテンツをWebでパブリックに配信する場合には、ブロックパブリックアクセスをオンにしたままバケットポリシーを以下のように設定すると覚えてください。

例えば以下のようになります。

{
    "Version": "2012-10-17",
    "Statement": {
        "Sid": "AllowCloudFrontServicePrincipalReadOnly",
        "Effect": "Allow",
        "Principal": {
            "Service": "cloudfront.amazonaws.com"
        },
        "Action": "s3:GetObject",
        "Resource": "arn:aws:s3:::<S3 bucket name>/*",
        "Condition": {
            "StringEquals": {
                "AWS:SourceArn": "arn:aws:cloudfront::111122223333:distribution/<CloudFront distribution ID>"
            }
        }
    }
}

この設定を行う場合、CloudFrontのOACという設定と連動します。詳細はAmazon Simple Storage Service オリジンへのアクセスの制限 - Amazon CloudFrontを参照してください。

その他のバケットポリシーのユースケースや例はバケットポリシーの例 - Amazon Simple Storage Serviceを参照してください。

■重要なデータはバックアップを取得する

ビジネスに重要なデータを保管する場合、この可用性は重要な要件の1つです。うっかり削除したり悪意を持った内部・外部の脅威からデータを保護するためにバックアップを取得しましょう。S3バケットではバージョニングの設定で以前の状態に簡単に復元できるため、誤った更新などに対する即時の復旧に役立ちます。悪意を持った削除に対しては、別のAWSアカウントのS3バケットにレプリケーションすることで、データの喪失を防ぐことが可能です。

■機密情報など誰が閲覧・変更したかが重要なS3バケットではアクセスログを記録する

データに対するリスクは喪失だけではありません。閲覧されるだけでも問題になる機密情報などもあります。アクセスを制御することが一番大事ですが、適切に制御できているかを確認したり、万が一漏洩した場合でもそのアクセスの記録を取得し、何が起きたかを確認できるようにすることも重要です。S3に対するアクセスの記録は下記2つの手法で取得できます。

• S3バケットのサーバーアクセスログ
• CloudTrailのS3データイベント

機密情報などに対するアクセスを記録する場合には、CloudTrailのS3データイベントのほうがおすすめです。詳細はCloudTrail S3オブジェクトレベルログ、S3サーバーアクセスログ、どちらを使えば良いか？違いをまとめてみた | DevelopersIOを参照してください。

その他S3のセキュリティベストプラクティスについてより詳しく知りたい方はAmazon S3 のセキュリティのベストプラクティス - Amazon Simple Storage Serviceを参照してください。

4-3.EC2に対するネットワークのアクセス制御

Amazon EC2は汎用的なコンピューティングリソースです。簡単に言うとサーバーの役割を担うサービスです。Web/アプリケーションサーバーとして利用することもあれば、データの処理やバッチ処理に活用することもあります。

EC2はVPCという仮想ネットワークの中に構築しサービスを提供します。例えばWebシステムを構築してインターネットで公開する場合、エンドユーザーはインターネットからVPCに入り、EC2へアクセスします。特にEC2などのVPC内に構築するリソースは、VPCにおけるネットワークアクセス制御を実施する必要があります。

4-3-1.EC2利用時のよくある事故

EC2でWebシステムなどを構築して外部に公開する場合でも、基本的にインターネットから直接誰でもEC2に接続できるようにする必要はありません。代わりに、Webアクセスの入口となりセキュリティや可用性を向上させるALBなどのロードバランサーを手前に配置し、EC2はプライベートなネットワークに設置して保護します。このような正しい利用をせず、EC2をパブリックなネットワークに配置し、ネットワークのアクセス制御を誤ってしまうことで、第三者にサーバーへの侵入を許し、マルウェアに感染させられたり、さらなる攻撃の踏み台にされる場合があります。ひどい場合ではここからさらに、EC2にアタッチされたAWSの権限を利用してAWS側が乗っ取られる場合もあります。EC2への侵入から始まり、事故の被害は提供しているサービス利用者への被害や、AWS上での機密情報の搾取、EC2を乱立してコインマイニングされることによる金銭的被害まで広がります。

4-3-2.EC2におけるネットワークのアクセス制御

VPC内のネットワークアクセス制御はITネットワーク技術も合わせて理解する必要があります。主にL3-4の技術です。これを制御するための主なVPCの機能は以下2種類です。

• セキュリティグループ
• ネットワークACL

セキュリティグループはVPC上の各種リソースにアタッチし詳細なアクセス制御を行い仮想ファイアウォールとして機能します。アクセス制御の設定は、リソース外側からリソースへの通信であるインバウンド通信と、リソースからリソース外部への通信であるアウトバウンド通信の2つに対して許可のルールを記述する方式で設定します。デフォルトではインバウンドルールは何も記述されておらずすべて許可されていない状態で、アウトバウンドルールは0.0.0.0/0 と::/0の送信先に対してすべてのプロトコルとすべてのポートが許可されている状態です。

基本的にはインバウンドルールを用途に合わせて最低限許可する使い方です。

ネットワークACLはVPCの分割単位であるサブネットに対して包括的に適用するアクセス制御です。セキュリティグループと違い個別のリソースに適用するわけではないため、ざっくりしたポリシーとして適用する使い方です。セキュリティグループに比べてネットワークACLのいいところは、明示的な拒否のルールを設定できることです。例えば誤ってセキュリティグループでSSHのポートを開放してしまった場合でも、ネットワークACLによりこれを拒否する、などの使い方が可能です。

基本的にはセキュリティグループで詳細な制御を行い、本当に許可したくない通信をネットワークACLで拒否していく使い方になりますが、これからAWSを使い始めるような場合にはまずセキュリティグループのみに注力し、ネットワークACLについてはデフォルトのままでも良いでしょう。

4-3-3.最初に知っておくEC2ベストプラクティス

EC2を始めVPC上に存在するネットワークリソースを保護するため、以下のベストプラクティスを心に刻んでください。

■SSHを0.0.0.0/0で許可しない

SSHは管理アクセスのために利用するプロトコルです。これを不特定多数のアクセスが発生するような利用をすべきではありません。セキュリティグループでSSHを0.0.0.0/0で設定している主な言い訳は以下のとおりです。

• 複数のメンバーが自宅から作業するため
• 外部の業者が利用するため
• いざというときにどこからでも作業したいため

いずれの理由もリスクに対して釣り合いません。

「公開鍵認証しか許可していないから0.0.0.0/0で公開しても安全だ」という言い訳も間違っています。SSHをインターネット経由で利用できるようにサービスしていると、sshdなどの脆弱性が見つかった際に攻撃されます。管理アクセスですからそもそも必要外のアクセスを許可してはいけません。管理アクセスと言う性質上、送信元IPは必ず/32のレベルまで絞ってあるべきです。送信元IPを絞れないなら動的に登録解除を行いましょう。

理想的には、そもそもSSHを利用すべきではありません。AWS上でEC2に対する管理アクセスを行う場合には、AWS Systems Manager Session Manager機能を利用することで、SSHをサービスしていなくてもAWSの権限で管理アクセスすることが可能です。現在のベストプラクティスは、SSHを公開せずSession Managerでアクセスすることです。Session Managerを利用したEC2へのシェルアクセス方法はセッションマネージャーを使って鍵ストレスの無いEC2アクセス！ | DevelopersIOを参照してください。

■脆弱なプロトコルを利用しない

上記SSH以外にも、インターネットに公開しているとリスクの高いサービスはあります。FTPやTelnetなどは0.0.0.0/0で公開しないこともそうですが、そもそも安全ではないプロトコルのため利用すべきではありません。インターネットを通過する通信はすべて暗号化するために、TLS等の暗号化に対応したプロトコルを利用しましょう。

■セキュリティグループのルールにはセキュリティグループIDを活用する

VPC間の通信を許可する際に、セキュリティグループでVPC全体やサブネット全体のネットワークアドレスを指定してアクセスを許可することは、最小権限の原則に反します。セキュリティグループは各VPCリソースに役割としてアタッチして使うと適切です。そして、その役割からのアクセスを許可したい場合、セキュリティグループのルールに直接IPを記述するのではなく、その役割のセキュリティグループIDを指定することで、わかりやすくかつ最小権限の原則を満たしたルールを設定することが可能です。以下の図のように、マネジメントコンソールのルール設定画面ではセキュリティグループの名前等を入力することで候補が出てくるため、簡単に最小権限を実現できます。基本的にVPCの外からのアクセス許可以外はすべてセキュリティグループIDで指定しましょう。

■システムごとVPCレベルで分割する

VPCは論理的なネットワークの境界線です。ネットワークをシンプルに、管理しやすく、周囲への影響範囲を小さく、セキュアに保つために極力システムを共存させないようにVPCを分割しましょう。VPC自体やネットワーク周りのリソースはほとんど費用がかからないため、まとめるメリットはほぼありません。セキュリティの原則としても、「シンプルに保つこと」が挙げられます。無意味な共存は弊害にしかなりません。VPCを分割しましょう。

■最新のパッチを適用する

サーバーを運用していると、OS/ミドルウェア/アプリケーションライブラリなどでセキュリティパッチを含めたパッチ適用が必要になります。パッチが適用されていなければ、安全であるはずのサーバーが侵入されてしまう可能性もあります。常にパッチの情報を収集し、検証を行い、パッチ適用をする運用をしましょう。このためには、定められたアプリケーションのテストとデプロイの仕組みが必要です。可能なら自動化されているといいでしょう。

EC2のセキュリティパッチが適用されていない場合、AWS Systems Manager Patch Managerでこれを検出し、パッチ適用を行うことが可能です。あるいは、脆弱性を診断管理するAmazon Inspectorにより脆弱性のレベルを評価しリスクに応じた対応を検討できます。現在ではAmazon Inspectorを有効化するだけで、AWSアカウント全体で包括的に、EC2だけでなくECR/Lambdaも含めて脆弱性管理が可能となるため、まず有効化することを検討しましょう。Amazon InspectorについてはAWS入門ブログリレー2024〜 Amazon Inspector 編〜 | DevelopersIOを参照してください。

ネットワーク以外にもEC2を保護するための要素はたくさんありますが、第1に守ることは間違いなくネットワークでのアクセス制御です。EC2のインフラストラクチャセキュリティベストプラクティスについてはAmazon EC2 でのインフラストラクチャセキュリティ - Amazon Elastic Compute Cloudを、その他のセキュリティについてはAmazon EC2 のベストプラクティス - Amazon Elastic Compute Cloudを参照してください。VPCのセキュリティベストプラクティスについてはVPC のセキュリティのベストプラクティス - Amazon Virtual Private Cloudを参照してください。

5.まとめ

以上を簡単にまとめると以下のとおりです。

• クラウドの特性を理解しビジネスを促進するためにセキュリティにも取り組む
• 情報セキュリティの基本であるアクセス制御を徹底する
• IAMにMFAを設定しアクセスキーはプログラムに埋め込まない
• S3に保存したデータを識別し不必要な公開をしない
• EC2のSSHは公開せずSession Managerを利用する

自信を持って安全にAWSを利用し始める準備はできましたか？1度目を通しただけではすべての項目について理解できていないかもしれません。繰り返し読み知らない単語や概念を調査し、理解しながらAWSに取り組み始めましょう。