AWSのセキュリティあるある…気づかないと危険!3つの落とし穴

IT・IT製品TOP > Key Conductors > 吉田 浩和(アイレット株式会社) > AWSのセキュリティあるある…気づかないと危険!3つの落とし穴
この記事をtweetする このエントリーをはてなブックマークに追加

IT現場の道先案内人 Key Conductors

AWSのセキュリティあるある…気づかないと危険!3つの落とし穴

データセンター 2016/02/12

 今回は、AWS導入企業がついやってしまう、あるいは気がつかずに放置しているセキュリティの3つの落とし穴を説明します。知らぬ間に設定ミスを冒すケースもありますし、運用を続けるなかでシステムをどんどん拡張していくことで、徐々にシステムのセキュリティレベルが低下していくケースもあります。

【あるある…その1】セキュリティグループが適切に設定されていない

 もっとも多いのが、AWSで特有の「セキュリティグループの設定」がおろそかになってしまうことです。セキュリティグループ設定は、AWSのファイアウォールに相当する機能ですから、適切に使わないと外部からの不正アクセスを引き起こす要因となります。

 「セキュリティグループ」とは、サーバーごとに適用できる仮想ファイアウォール設定のルールのセットという意味で捉えればよいでしょう。これはAWSならではの便利な特長です。送信元/送信先IPアドレスの設定や、どのプロトコルを通すかといったファイアウォールのルール(セキュリティグループ)を複数作ることができます。例えば、社内からAWS環境へアクセスする場合のルール、システム構築の協力会社がアクセスする場合のルール、テスト用のルール、などと各種のセキュリティグループをサーバーごとに複数設定できます。

 パブリックサブネットで作られたサーバーには「パブリックIPアドレス」をDHCPサーバーから割り当てることができます。そのIPアドレスには、セキュリティグループルールで許可されている外部からの通信だけが到達できることになります(図1)。

図1 インターネットと接続する場合のパブリックサブネットのイメージ

※会員登録いただくと図をご覧いただけます。
会員登録はこちら(無料)

図1 インターネットと接続する場合のパブリックサブネットのイメージ

 開発工程やサーバーの役割によってルールをきちんと使い分け、サーバーごとに適切に安全なルールを適用できれば問題ないのですが、実際には構築時やメンテナンス時に開けたポートが、そのまま閉じられずに開いたままになっていることがあります。

 不正アクセスを狙う攻撃者は、まずインターネットを通して開いているポートを探索し、攻撃しやすいポートが開いているシステムを狙い撃ちにするのが常套手段です。必要のないポートが開いていると、それだけで攻撃者を呼び込んでいることになります。絨毯爆撃のように無差別に送信される攻撃通信は開いているポートに到達します。したがって、IPアドレスは外部に公表していないのだから安全だろうと考えるのは間違いです。

 また特に危険なのはメンテナンスなど効率をよくしたいと考えて、外部のどのIPアドレスからでもSSHやRDP(運用管理用のプロトコル)で接続できるように設定してしまい、それが本番業務でも使われることです。受け入れる送信元アドレスを「0.0.0.0/0」に設定すると、どのIPアドレスからでも接続可能になります。その設定はすぐに攻撃者に探り当てられ、簡単にシステムを不正に操作されてしまうことになってしまうのです。テストなどでやむを得ず、ごく短期間設定する場合は、公開鍵認証方式や複雑かつ十分な桁数のパスワードを利用するのがよいでしょう。

 設定の甘いサーバーが一度でも不正アクセスを許してしまうと、そのサーバーは攻撃の「踏み台」に使われ、他のサーバーに攻撃をしかけることも可能になります。サブネットで区分けされているとしても、企業システムでは相互に接続されているのが普通なので、最も甘いセキュリティ設定のサーバーが全体のセキュリティレベルを決めることになります。

 インターネットに接続する必要のあるサーバーなら、適切なセキュリティグループルールを作り、適用していくことに気を配る必要があるというわけです。ただし、セキュリティグループの数が増えてくると管理が煩雑になり、ミスが発生しやすくなります。開放するポートを絞り込みすぎることによるサービスへの支障はすぐに気づきますが、開けすぎについてはなかなか気づけません。「踏み台」として悪用された場合、最悪の場合はAWSによって危険と判断され、アカウントをロックされることもあります。そこで、パブリックサブネットとインターネットから直接アクセスのできない「プライベートサブネット」を組み合わせて使うことが推奨できます。その方法は利用企業のシステムの性質と合わせて考える必要がありますので、説明は次回の記事といたします。

【あるある…その2】オンプレミス構築で慣れたパスワード認証に頼ってしまう

 次によくあるのが、従来のオンプレミス構築システムで利用してきたパスワード認証をAWSでも踏襲してしまうことです。社屋内でクローズした環境とは違い、クラウドではセキュリティグループの設定でSSHやRDPのポートを開放してしまうと誰でも外部からID/パスワードでアクセスできることに注意が必要です。パスワードクラッキングの自動化ツールを用いれば、簡単なパスワードなら短時間で破られてしまいます。SSHやRDPのポートを制限なく開いた状態でパスワード認証だけに頼っていると、攻略されるのは時間の問題です。

 そこで、Linux環境においては公開鍵認証方式(PKI)を利用することを強くお勧めします。ユーザーとAWSのサーバーとの間で保有する公開鍵と秘密鍵を作成して、互いの相手を確実に認証できる最も安全な認証方式です。ただし問題はユーザー側で鍵生成を行う手間がかかることで、これを嫌がってわざとパスワード認証のみの設定にしてしまうことがあります。枯れた手法でもあり、手順はインターネットに多数公開されているので、わずかな手間を惜しまず、ぜひ利用するようにしたいものです。

 なお、同じ公開鍵認証でも、AWSが標準で提供している管理者用の特別な鍵(root鍵)は、Linux環境で言うところのrootユーザに相当するため、使用しないように運用上のルールの整備も合わせて行う必要があります。

 同様にAWSアカウント作成時に作成されるAWS管理者アカウント(アカウント作成時のメールアドレスがユーザ名)はMFA(Multi-Factor Authentication/多段階認証)を設定して原則として使用せず、運用では権限を絞ったIAMユーザーで運用することもAWSでは可能になっています。MFAを用いた認証がなじまない場合でも、こうした手法で安全な運用を図ることが重要です。

【あるある…その3】マシンイメージの「雛形運用」でシステムが時代遅れになる

 もう1つ指摘しておきたいのは、サーバー拡張時に仮想マシンイメージ(AMI/Amazon Machine Image)をコピーする「雛形運用」の危険性です。OSやミドルウェアはアップデートすることで、脆弱性を解消していきますが、雛形となるマシンイメージをアップデートしないままコピーして使い回している企業が案外多いのです。

 マシンイメージのコピーという簡単な手段でサーバーが複製できるのがAWS利用の大きな利点ではありますが、運用が適切でないと、古い脆弱性を残したままのサーバーが様々なサービス向けに複製されていくことになってしまいます。実際、一昨年に大問題となったbashの脆弱性(ShellShock)に対応していないサーバーが複製されていたケースも見受けられました。もちろん大きなリスクをはらんでいますので、すぐに最新のアップデートを反映することをお勧めしています。

 なお、Linuxのカーネルもバージョンアップがあります。影響が大きいため、うっかりミスを防ぐためにアップデートを無効化している場合がありますが、それに気づかずマシンイメージのコピーから起動後にアップデートを実行して安心してしまう場合があります。
 
 オリジナルの仮想マシンイメージを作りたくなるのは当然なのですが、アップデートにともなう依存関係の問題を考えるとアップデートに即座に対応する運用を行うのはなかなか大変です。メンテナンスやテストの自動化などへの投資を考えなければならないケースもあるでしょう。オリジナルAMIにこだわる必要がなければ、一策としてAWSが提供するAmazon Linux AMIやを利用する方法もあります。これなら常に最新のイメージが利用できますからメンテナンスの手間は軽減します。 

まとめ

 セキュリティ対策には、オンプレミス環境と同様に「利便性」「生産性」「安全性」を天秤にかけなければならないことがよくあります。以上に述べた3つの「あるある」も、意識されているか否かとは別に、基本的には宿命的とも言えるこのトレードオフが原因です。コストを抑えつつ最適なバランスはどうすれば取れるか、次回はセキュリティ意識と体制面から考えてみます。

会員限定で「読者からのコメント」が読み書きできます! 「読者からのコメント」は会員限定の機能。会員登録を行い、ログインすると読者からのコメントが読み書きできるようになります。

会員登録(無料)・ログイン

Myリストへ 印刷用ページへ

この記事をtweetする このエントリーをはてなブックマークに追加


この寄稿記事に掲載している情報は、掲載日時点での情報となります。内容は変更となる場合がございますのでご了承下さい。また、「Key Conductors」の寄稿記事及び当該記事に寄せられたコメントについては、執筆者及びコメント投稿者の責任のもと掲載されているものであり、当社が、内容の最新性、真実性、合法性、安全性、適切性、有用性等を保証するものではありません。


30008562


IT・IT製品TOP > Key Conductors > 吉田 浩和(アイレット株式会社) > AWSのセキュリティあるある…気づかないと危険!3つの落とし穴

このページの先頭へ

Key Conductors Award 2016 上半期受賞者 発表
キーマンズネットとは
AWS認定ソリューションアーキテクト。AWSプレミアコンサルティングパートナーであるcloudpackにjoin後、インフラ構築チームリーダーを経て、2014年4月からcloudpackが提供開始したDeep Security 運用代行サービス「securitypack」の運用責任者を務める。「セキュリティは運用が命」を信条に日夜情報発信する。

ページトップへ