エンジニア志望生、AWSを使って勉強したら料金爆弾された！

エンジニア志望者が集まるコミュニティには、「勉強のために使用していたAWSアカウントに突然数百万ウォンの料金が請求された」という怖い話があります。このレベルの料金爆弾は、通常、悪意のあるユーザーに権限を奪われたときに発生します。今回のポストでは、悪意のあるユーザーからAWSアカウントを保護する方法をご紹介します。

悪意のあるユーザーから AWS アカウントを保護する方法をお知らせします。

1. クラウドセキュリティはルート(root)アカウント保護から

AWSに初めてサインアップしたときにアクセスするアカウントは、ルートアカウントです。「大きな力には大きな責任が負われる」という言葉があります。ルートアカウントにはどれほど大きな力がありますか？

AWS に存在するすべてのリソースを作成、変更、削除できます。数百台の仮想マシンを作成して料金爆弾を課すことも、サービスに使用していたDBを削除することもできます。

他のユーザーに権限を配分または奪うことができます。

会員脱退ができます。

手に負えない程の大きな力です。小さな力だけを使って、小さな責任を負う方法について学びましょう。

a. パスワード管理

パスワード管理は最も基本的なセキュリティ対策です。他の認証手段と比べたら漏洩に対して脆弱であるため、以下の事項を遵守するように管理する必要があります。

ランダムに生成された長いパスワードを使って予測しにくくします。

パスワードは誰にも見えないように安全な媒体に保管してください。付箋にメモしてモニターに貼っておくなどの行為は絶対禁物です。

ルートアカウントのパスワードは少数の担当者だけが知るようにします。また、定期的に修正してメモや暗記による再使用ができないようにします。

b. マルチファクタ認証(MFA)の有効化

マルチファクタ認証とは、IDとパスワード以外の確認手段をさらに使用する認証方式のことです。AWSでMFAを有効にすると、既存の ID パスワードとともにOTP(One-time password)を正確に入力しないとアカウントを使用できなくなります。OTPは30秒ごとに再生成される使い捨てパスワードです。パスワードのみを使用する方法に比べて、どのようなメリットがあるかを見てみましょう。

一般的なパスワードは、以下の原因によってハッカーに奪取される可能性があります。

複数のサイトで同じパスワードを使用する人が多いため、セキュリティが脆弱な1つのサービスだけをハッキングしても、複数のアカウントを奪取する効果があります。

パスワードを定期的に交換しない人が多く、一度消臭したパスワードを長く使用することができます。会社が使用するパスワードの場合、交換しないと退社者が利用する可能性があります。

パスワードでよく使われる単語を代入してみる辞書攻撃(Dictionary attack)に遭遇することがあります。

OTPを併用すると、パスワードの脆弱性を相当補完することができます。

サービスごとに別々のOTPを使用するため、他のサービスのものをリサイクルすることはできません。

30秒ごとに自動的に交換されるため、ハッカーがOTPを奪取してもすぐに無用物になります。

ランダムに生成されるので、事前攻撃が無意味です。

c.
Access key 未発行

IDとパスワードはAWSウェブコンソールにアクセスするために使用されます。CLIまたはSDKを使用したい場合は、Access keyとSecret keyがそれぞれIDとパスワードの役割に代わるものです。したがって、これら2つのキーを奪取すると、IDとパスワードを渡したのとほぼ同じ効果があります。幸いなことは、Access keyはユーザーが別に要求しないと生成されないため、作成しないことが安全です。

d. ログイン通知の使用

誰かがルートアカウントにログインするたびに通知が発生するように設定しておくと、迅速な対応ができます。通知を実装するには、AWSクラウドウォッチにログイン履歴が残るたびにメールまたはメッセージを送信するラムダを作成します。AWSの公式ブログに方法をよく説明した記事があり、リンクを残します。

Monitor and Notify on AWS Account Root User Activity

ルートアカウントにはなるべく使用しないことをお勧めします。

上記の基本的な保護方法を適用した場合は、ルートアカウントの接続を厳密に制限する必要があります。ルートアカウントのほとんどの権限は、後述するIAMを介して他のユーザーに譲渡できます。決済設定の変更など、必ずルートアカウントが必要な場合でない場合は、まったく使用しないようにしましょう。

2. IAMによるアクセス制御

IAMはIdentity and Access Managementの略で、ユーザーやリソースに付与した ID に合った権限のみを使用するように制御するサービスです。会社の従業員は、所属と職級、つまり身元によって必要な権限が異なります。たとえば、DB管理者にはDBの変更権限が必要ですが、Kubernetesクラスターの操作権限は必要ありません。逆に、KubernetesのエンジニアにはDBに関連する権限は必要ありません。IAMを使用すると、各ユーザーに必要な権限のみを付与できます。簡単に言えば、Kubernetesエンジニアのアカウントが奪取されても、DBは攻撃されないようにすることができます。

どのような権限を付与するかをあらかじめ決めたものをIAMポリシー(Policy)といいます。たとえば、「開発用Kubernetesクラスタの状態を照会できる」というポリシーがあるとしましょう。開発用クラスタにのみ権限があり、運営用にはありません。また照会のみできて、修正と削除はできません。こういうことを決めておくのがまさにポリシーです。

IAMのアイデンティティは大きく「ユーザー(User)」と「役割(Role)」に分けられます。役割の説明は後にして、ユーザーから見てみましょう。ユーザーとは、AWS にログインできるアカウントです。IDとパスワード、あるいはAccess keyとSecret keyを使ってログインして運用作業を行います。アイデンティティにポリシーをリンクすること、すなわち「開発者のホンギルドンのアカウント」というアイデンティティに「開発用Kubernetesクラスターの照会を許可する」というポリシーをリンクすることが IAM運営の基本です。

a. IAMユーザーのマルチファクタ認証(MFA)の有効化

IAM ユーザーアカウントもルートアカウントのようにマルチファクタ認証を有効にできます。ログインプロセスはやや面倒ですが、はるかに安全です。

b. Access keyの管理

先ほど、ルートアカウントのAccess keyを絶対に発行しないようにと話しました。IAMユーザーの発行まで全面制限するのは無理です。ただし、Access key を必ず発行しても、作業が終わったらすぐに削除することをお勧めします。前述のように、有効なAccess keyとSecret keyのペアが流出したときの波及効果は、アカウント全体を奪取されたときとほぼ同じだからです。できるだけ短い時間だけを使用することは、奪取のリスクを減らす方法です。

特にGithubのような公開された場所にAccess keyとSecret keyを投稿する行動は絶対にしてはいけません。今でも多くのハッカーが公開されたAccess keyを探すクローラを実行しています。Githubにキーを公開した瞬間、あなたのアカウントはハッカーの公共財になります。

c. 最小限の権限のみを付与

操作中に権限の不足によるエラーに直面すると、IAMポリシーをワイルドカード(*)に設定して、すべての権限をもらいたい強い誘惑に向き合ってしまいます。このような行動はルートアカウントをもう一つ作るのと同じ行動なので絶対禁物です。苦労しても、作業に必要な最小限の権限を見つけて付与する必要があります。

d. なるべく IAM 役割を使用

IAM役割は、適切な権限を持つユーザー、またはリソースに一定時間だけ有効なAccess keyとSecret keyを発行する認証方式です。OTPと同様に流出しても一定時間が経過すると期限切れになりますので、より安全です。

IAM役割はユーザーにも付与できますが、最終的に役割を付与するための認証プロセスでAccess keyを使用する必要があるため、制限があります。IAMの役割は、リソースに付与されたときにその真価が明らかになります。たとえば、ec2仮想マシンにサービスをデプロイするためにs3のファイルをダウンロードする必要があるとします。ec2にs3のダウンロード権限を付与すると、Access Keyを入力したり保存したりしなくてもファイルをダウンロードできます。キーを入力するプロセスは省略されるため、スクリプトによる自動化に適した方法です。

セキュリティポリシーを確立し、クラウド費用爆弾に備えてください

クラウドセキュリティ事故は、手に負えないほど財政的損害を受ける可能性があります。悪意のあるユーザーの侵害が明確な場合は払い戻してもらえますが、手続きが複雑であって100％救済されるという保証もありません。事前にセキュリティポリシーを設定してアカウントを保護するのが最善の方法です。

목차