.png){kind=small}
Vol.03 まずはこれだけ！クラウドセキュリティの第一歩
- mitsuruto32
- 5月8日
- 読了時間: 13分
この記事であなたがやるべきこと
クラウドセキュリティの第一歩として最低限やるべきこと4項目で紹介しているものを理解し、実践すること
やるべきことに加え、考え方や思想を含めて理解し、他の分野においても応用できるようになること
もう一歩発展的な内容を学びたい際に、どのように進めれば良いか理解すること
はじめに
ここ数年でシステムのクラウド化は一気に進み、いまやクラウドは「新しい」ものではなく「当たり前」になりつつあります。業務やプロジェクトで利用する機会も多いと思いますが、エンジニアの個人学習のための環境としてクラウドを使うケースも増えてきているでしょう。
そんな中で、皆さんはクラウドのセキュリティ対策について自信はありますか？クラウドは、インターネット経由で気軽にアクセスできることが便利な反面、自分以外の第三者も管理画面やシステムそのものに簡単にたどり着ける設定にできてしまうリスクがあります。業務システムの本番環境は当然として、学習用の個人アカウントも含めて、最低限の対策はしておかないと攻撃を受けて損失を被るリスクがあります。
「学習用アカウントなんて何も大事なもの動いてないからいいじゃん！」って思うかもしれませんが、"EDoS攻撃を受けて仮想通貨のマイニングに使われた結果、莫大な請求を食らって真っ青"っていう事例も実際にあるので、本当に油断は禁物です。
とはいえ、クラウドセキュリティというテーマにおいてはたくさんの切り口、サービスがあり、すぐに実践できることから多大な時間と費用をかけて組織レベルで行うものまでさまざまなものが出てくるため、何から手を付けるか悩んでしまう方も多いでしょう。
「クラウドシステムを触り始めたインフラエンジニアだけど、セキュリティ関連の勉強は正直気乗りしない」
「クラウドで学習用環境作っているけど、別にクラウドエンジニアってわけではないから、クラウドセキュリティ対策は最低限で済ませたいのが本音」
こんな思いを持っている方も少なくないと思います。
そこで、今回はクラウドセキュリティとして「まずはこれだけはやっておけ」というものを本記事で紹介します。クラウドのセキュリティ対策を学ぶ上で、何から手を付けるか悩んでいる方はぜひご一読ください。
クラウドにおけるセキュリティの考え方「責任共有モデル」
ご存じの方も多いかもしれませんがクラウド特有のセキュリティの考え方として重要な「責任共有モデル」について先に触れておきます。
オンプレミスとクラウドにおける一番の考え方の違いは、コンポーネントやレイヤーによってクラウド事業者と利用者（＝クラウドでシステムを作るベンダー企業や、そのシステムを保有/管理するユーザー企業等）のどちらが責任を持つかが変わるということです。
例えば、オンプレミスでシステムを構築する場合、企業自身のサーバールームやデータセンター等にサーバー、ネットワーク機器等のハードウェアを設置して構築し、故障時の対応は企業側で実施する必要がありました。一方、クラウドにおいては、データセンターもハードウェアもクラウド事業者が提供し、災害やセキュリティ事故も含めて何かあった場合はクラウド事業者が責任をもって対処します。一方で、利用者側で自由に設定を入れられる部分は、クラウド事業者側ではなく利用者側が責任を負います。これを「責任共有モデル」と言います。
クラウドにおける責任分界点は、サービスの提供形態によって異なります。有名な分け方でいうと、SaaS、PaaS、IaaSがあります。
区分 | クラウド事業者が提供するもの | サービス例 | 備考 |
SaaS（Software as a Service） | アプリケーションまでまるごと提供 | Gmail、Microsoft 365、Slack等 | ユーザーが責任を持つ範囲は限りなく狭い |
PaaS（Platform as a Service） | ミドルウェアやランタイム（≒アプリの実行環境）まで提供 | Amazon RDS、AWS Elastic Beanstalk、Google App Engine等 | データやアプリケーションについてはユーザーが責任を持つ |
IaaS（Infrastructure as a Service） | OSレイヤーまで提供 | AWS EC2、Azure VM等 | OSからミドルウェアも含めてすべてユーザーでセキュリティ設定を対応 |
オンプレミスのセキュリティ対策の頭のまま対策を立てようとすると、クラウドでは過剰になることも多いです。一方で、「クラウドだから、セキュリティはクラウドベンダーがいい感じにやってくれてるでしょ」と思考停止するのは危険です。例えばIaaSではOSレイヤーのセキュリティ設定はユーザーで行う必要がありますし、IDS/IPSやウイルス対策をしたいとなった場合も、マネージドサービスやサードパーティー製品を含めてやり方からユーザー側で考える必要があります。
クラウドにおいては、利用するサービスの責任境界を見極め、それに沿ったセキュリティ対策を行うことがポイントになります。
クラウドセキュリティ対策一覧
それではここから本題のクラウドセキュリティ対策の中身に入ります。「まずはこれだけ！クラウドセキュリティの第一歩」というテーマに沿って、今回は以下の4つを紹介します。
管理コンソール画面へのアクセスはMFA＋IP制限で
無期限のアクセスキー、シークレットキーは基本使わない
利用料金アラートで費用の高騰に気づく仕組みづくり
CSPMで設定ミス対策
管理コンソール画面へのアクセスはMFA＋IP制限で
クラウドにおける管理コンソール画面とは、AWSでいうマネジメントコンソールのように、各クラウドのリソースの設定を閲覧/変更することができるGUI管理画面のことを指します。クラウドにおいては、EC2で仮想サーバーを立てたり、Lambdaでアプリ環境を用意したりといった各種クラウドのリソース作成動作は基本的に管理コンソール画面から行います。（もちろん、CLIやAPIで行われることもありますが、一番簡単かつ標準で使われるのはGUIである管理コンソールになります）
管理コンソールへのログイン画面というのはインターネット上に公開されているため、誰でも到達できます。つまり、自分のアカウントへのログイン情報が洩れたら世界中のどこからでもアクセスできてしまうのです。これは冷静に考えると怖いことですよね。そのため、クラウドの管理コンソールログインに対するセキュリティ対策は非常に重要度が高いのです。
本番環境でも、開発環境でも、個人の勉強用環境にしろ、最初にやることは、ルートユーザーだけでなく全IAMユーザーを含めて、管理コンソールに入れるユーザーで多要素認証（MFA）を有効化することです。もっと言うと、MFAを強制させる（初回ログイン時にMFAの登録を要求する）まで必須にしてしまうことを推奨します。
AWSにおけるMFA強制は、IAMポリシーを使って「MFA登録していない場合は全リソースへの操作を拒否する」というルールを書いて実現します。記載例はインターネット上で検索すれば腐るほど落ちていますが、一例を以下に記載します。
※「MFAするまで何もさせない」というシンプルなルールなのになんか色々書いてない？と感じるかもしれませんが、これはMFAを登録する前でもMFAデバイスの登録等の操作は許可はしないといけないためです。これをしないとMFA登録まではMFA登録すらできないという矛盾が発生してしまうので...。
ちなみに注意点として、AWS公式ドキュメントでも上記みたいなポリシーはよく見かけますが、なぜか「iam:ChangePassword」が入っていないので、新規作成後のIAMユーザーの初回ログイン後にパスワードのリセットを強制している場合、AWS公式ドキュメントのポリシーを真似するとパスワード変更のときにコケます。よくあるトラブルなのでご注意ください。
また、MFAに加えてやれるといいのがIP制限です。例えば、本番環境のAWSアカウントのマネジメントコンソールへのアクセスは会社の本番アクセスルームからに限定したい場合、IAMポリシーで以下のように記述することで制限が行えます。
ちなみに、この設定を失敗すると自分もマネジメントコンソールにアクセスできなくなるリスクがあるのでご注意ください。そうなってしまった場合、ルートユーザーでアクセスしてIAMポリシーを直すか、AWSサポートに問い合わせるなどの対処方法を行う必要があります。
なお、MFAは個人の学習用アカウントでも必ずやっておくことを推奨しますが、IP制限の方は実施しないことを推奨します。理由はよくある質問に記載します。
無期限のアクセスキーは基本使わない
クラウドにおけるCLIの認証方法としてアクセスキーというもの※がありますが、これは漏洩するとクラウドリソースへの不正アクセス/操作を可能にしてしまうという重大なリスクがあるものです。実際、GitHubに誤ってAWSアクセスキーをPushしてしまい、真っ青になった経験のある方というのがWeb上だけでも複数人観測できます。
※クラウドサービスによって呼び名が異なります。サービスプリンシパルだったり、単にAPIキーだったり。
そのため、基本的にアクセスキーは発行しないのがベストプラクティスです。
「じゃあどうやってCLIで認証するんじゃい！」と思われた方もいるでしょう。そんな方に覚えていただきたい原則が「認証は期限付きのものを使うのがベター」ということです。
別記事でも「ジャストインタイム・アクセス」の話をしましたが、特にクラウドのCLIの認証はジャストインタイム・アクセス、つまり有効期限付きのセッションキーを利用するのが良いです。例えばAWSでいえば、Identity Centerから払い出されるAWS CLI用の一時アクセスキーや、AWS STS（Security Token Service）の有効期限付きassume-role等が該当します。
キーに有効期限がついていれば、万が一流出してしまった時のリスクを減らすことが出来ます。「無期限のアクセスキーは使わず、セッションキーを使うべき」というのを覚えておいてください。
利用料金アラートで費用の高騰に気づく仕組みづくり
クラウドでよくある恐ろしいトラブルの一つが、予期せぬ利用料金の高騰です。この原因は、主に2つのパターンがあります。
攻撃に起因するケース（例：冒頭にも触れたEDoS攻撃）
設定ミスに起因するケース（例：Lambdaで再帰的に自分を呼び出してしまって呼び出す回数が天文学的な数字になり、わずか数日で利用料金が数百万レベルになってしまう）
どちらのケースも、対策として利用料金アラートを設定することが有効です。利用料金アラートとは、「利用料金が●●円になったらアラート通知を飛ばす」という設定です。
例えば、普段の環境では課金が5万円/月の環境において、利用料金アラートを6万円に設定しておきます。この場合、利用料金アラートを受け取った場合、「アレ、超えるはずないんだけどな？」と異常に気付き、設定ミスや攻撃をはじめとする予期せぬ課金の増加に早い段階で対処できる可能性が上がります。また、「●●円を超えたら」という実測ベースの他、「月末に●●万円を超えそうなペースとなったら」という予測金額ベースでアラートを設定することもできます。
業務システムの本番環境はもちろん、自身の学習用の環境でも、とりあえず「これ以上課金されたらおかしい、気づきたい」という金額を決めて、まず利用料金アラートを設定しておくことをおすすめします。
CSPMで設定ミス対策
クラウドにおいては設定ミスによるセキュリティリスクが非常に問題視されており、クラウドセキュリティに関する懸念事項として最も重大な脅威に位置付けられたのが「設定ミス」であったというレポートもあります。それだけ設定ミスがセキュリティ事故に直結しやすく、発生頻度も高いということが伺えます。
設定ミスの対策としてはCloud Security Posture Management（以下、CSPM）の機能を持つマネージドサービスを利用することが有効です。CSPMは、設定ミスやコンプライアンス違反、脆弱性につながる設定などを自動で検知し、可視化したりアラート発報する仕組みです。いわゆる設定監査といわれるやつです。
AWSにおいてはAWS Configが該当します。例えば、パブリック公開されたS3や、パブリックIPが付与されたEC2、暗号化されていないRDS等を検知してアラート発報するという仕組みを簡単に作ることができます。様々なサービスに沿ったルールがあるので、今使っているサービスに合わせてルールを入れてみてください。
基本的に人間はミスをする生き物なので、設定ミスは注意力や根性でゼロにすることはできず、仕組みで防ぐのがベターとされています。CSPMはまさに仕組みで設定ミスを防ぐものです。
なお、AWS Configは、ものによっては検知だけでなく自動修復まで出来ますし、設定監査だけではなく構成管理にも使える優秀な子です。今まであまり知らなかった方は、ぜひAWS Configが何ができるのか調べてみてください。（地味ですが、筆者としては個人的には結構好きなサービスです。）
よくある疑問・注意点（Q&A）
Q1: AWSの事例ばかりだけど、他のクラウドではどうなの？
A: 基本的に考え方は同じです。具体例からイメージしてもらうために、最も触っている人口が多いであろうAWSをベースに語りましたが、最近は他クラウドもサービスが増えてきており、AzureやGoogle Cloud、OCIといった他クラウドでも、今回挙げたような仕組みを実現するサービスはできてきていることが多いです。他のクラウドを触るときも、今回話した4つのテーマから考えてみるのをおすすめします。
Q2: IAMポリシーによるマネジメントコンソールのIPアドレス制限って、個人の学習用AWSアカウントでもやったほうがいいの？
A: やめておいたほうがいいです。なぜなら、大体の場合、個人で利用するPCのグローバルIPは動的に変わってしまうからです。もし固定グローバルIPを契約しているのであれば別ですが、そうでない場合は、グローバルIPが変わったときに自分もログインできなくなってしまいます。
Q3: 今回挙げられた対策は終わった。次は何をすれば良い？
A: AWSのセキュリティ対策については様々な切り口でできることがありますし、情報も多いので迷うことも多いかもしれません。筆者がおすすめしたいのは、以下の2つのアプローチです。
AWSは「AWS Well-Architected Framework」という形で各カテゴリのベストプラクティスを示しています。これを読み込んだうえで自分の環境のセキュリティ対策に落とし込むことで、AWSが考えるセキュリティのベストプラクティスに沿った設計/構成とすることが出来ます。ただし、それなりにハードルは高くなります。
② AWS Trusted Advisorサービスを利用してセキュリティ関連の改善アドバイスを受ける
自分が実際に使っている環境に対して、セキュアでない設定を検知して警告してくれるので、自分の環境に即した具体的な対策をすぐに知ることが出来るのがメリットです。「①のWell-Architected Frameworkを読み込むのはハードル高いけど、もう少しできることがあるか知りたい」という方は、こちらから手を付けるのがいいでしょう。
また、書籍で学ぶのが苦手ではない方は「AWSではじめるクラウドセキュリティ」という本でクラウドセキュリティを学ぶことをおすすめします。この本はAWSを軸に書かれていますが、他クラウド、もっというとオンプレミスも含めて活用できるセキュリティ対策のナレッジが詰まっているので、クラウドセキュリティについて体系的/実践的に学びたい方にはうってつけです。
今日から実践！
クラウドセキュリティの第一歩のチェックリスト
管理コンソール画面へのアクセスはMFA＋IP制限で
ユーザーに対して、MFA登録を行うまでクラウドリソースの操作ができない設定を入れる
固定IPを使える環境であれば、管理コンソール画面操作を許可するIPアドレスを制限すると良い
無期限のアクセスキー、シークレットキーは基本使わない
時間制限付きのセッションキー（ジャストインタイム・アクセス）を使う
利用料金アラートを設定して、攻撃や設定ミスによる料金高等を検知できるようにする
個人の学習用アカウントだったとしても、EDoS対策に備えて設定すべき
CSPMで設定ミス対策
自環境で使っているサービスに即したルールを入れ込む
まとめ
今回はクラウドセキュリティの第一歩ということでご紹介しました。冒頭に述べた通り、クラウドセキュリティは色々なカテゴリが存在しており、かつクラウドにおいてどのサービスを利用しているのかによってやること/できることが大きく変わります（インターネット向けに公開しているのか、DBを使っているのか、IaaSを使っているのかPaaSまでなのか、等）
今回は、基本的にどんなサービスを使っていても該当する＆第一歩としてハードルが低いものを中心に紹介しました。まずはこれらを実践した後、これでは物足りず、もっと学びたい/実践したいという方は、先ほど紹介したAWS Well-Architected FrameworkやTrusted Advisor、書籍等から自分に合うものを使って学びを深めていただけると、よりクラウドセキュリティに強くなれるのではないかと思います。
今回の記事が、クラウドセキュリティの第一歩を踏み出したい方にとって少しでも有益なものになっていれば嬉しいです。最後までお読みいただき、ありがとうございました。
