AWSのセキュリティ対策って必要なのかな。
AWS側が全部やってくれているイメージだけど、実際どうなのだろう。
こちらで何か対策しないといけないのだろうか。
こういったお悩みを解決します。
■本記事の内容
本記事で以下の内容をお伝えします。
・AWSのセキュリティ対策のポイントについて
・セキュリティに関して心配性な方へお伝えしたいこと
■本記事の信頼性
この記事を書いている私は、プログラミングを仕事として始めて10年以上ほど経ちます。
今も現役のシステムエンジニアです。
AWSの経験は3年ほどです。AWSのアークテクチャの設計経験もあります。
以前、顧客からAWSってセキュリティ的にどうなの？みたいな漠然な質問をされたりして困った時期がありました。
もし、今その経験をされてこの記事を見て頂いた方のお力になれればと思います。
当記事で初心者向けにAWSで必要になる基本的なセキュリティの知識を知ることができます。
AWSを勉強しようとしている方、実際に業務で利用するか検討されている方など、比較的初心者向けに書いておりますので最後までお付き合いいただければ嬉しいです。
AWSのセキュリティ対策はそもそも必要？
結論から言うとAWSのセキュリティ対策は必要です。
私もAWSが既にセキュリティ対策してくれているから大丈夫でしょ！と思っておりましたが、実際に業務でセキュリティ対策の勉強していく上で概ねのポイントを理解することができました。
とはいえ、AWS側がセキュリティ的に何もしていないということではありません。
AWSとして標準のセキュリティについてどういったことをしているかを書いていきます。
まず、物理的なところの対策は以下のAWSページに記載しております。
https://aws.amazon.com/jp/compliance/data-center/data-centers/
普段、私たちがクラウドを利用する際はサーバ機器といったハード面について意識する必要はありません。
しかし、いろいろデータを保存している以上、どこかで何かしらサーバ機器を用意して運用していることになります。
これらの管理をAWS側が実施しています。
その他にも以下のページでセキュリティ対策するためのサービスが用意されています。
利用するサービスによってDDOS攻撃の対策などが標準で実施されているものがありますが、基本的にはこれらのサービスを利用してセキュリティ対策を実施していく必要があります。
AWSのセキュリティ対策のポイント
AWSのセキュリティ対策のポイントを書いていきたいと思います。
詳細に書くと直接AWSサイトへいって確認頂くほうがいい記事になってしまいますので、初心者向けにこのあたりは押さえておいたほうがいいという内容を書いていきます。
大きく観点としては以下の2点で書いていきます。
- 監視・制限
- コンプライアンス
上記の観点以外にもデータの暗号化もあります。
監視・制限
監視と制限を分けようかとも思いましたが、制限をかけれるものはほとんど監視機能も付いているため合わせて記載することにしました。
WAF
WEBアプリケーションファイアウォールになります。
APIGatewayやCloudFront、Application Load Balancerを利用している方は検討してみたほうがいいです。
WAFを導入する際はどういったルールを設定するかが課題となってきます。
厳しくしすぎると正常のアクセスも拒否されてしまうからです。
AWS WAFにはセキュリティを専門としているベンダーがルールを用意してくれているものがあり、これらを簡単に設定することができます。（お金はかかりますが）
なおかつ、新しい脆弱性などのセキュリティリスクがあれば、その都度このルールの内容も更新されていきます。
上記ベンダー以外にもAWSが提供してくれているAWS マネージドルールというものがあり、AWS マネージドルール自体の利用は追加料金なしで使用できます。
AWS IoT Device Defender
AWS IoTを利用されている方はAWS IoT Device Defenderを検討してみるといいです。
デバイスと双方向通信が可能なAWS IoTですが、これらの通信の監視を行えます。
AWS IoT セキュリティのベストプラクティスに従っているかチェックをしてくれるサービスになります。
あくまでチェックですのでアクセス拒否はされません。
他にも自信でルールを設定して、そのルールに従っているかモニタリングしてくれて、ルールから外れた動作をした場合は異常を検出してくれます。
Trusted Advisor
簡単に内容を説明すると利用しているAWS環境を以下の観点で推奨設定をアドバイスしてくれます。
- コスト最適化
- パフォーマンス
- セキュリティ
- 耐障害性
- サービスの制限
しかし、上記をフルチェックで利用するには、サポートをビジネスプランにしておく必要があります。（月100USDほどかかります）
ただ、ビジネスプランに加入することで上記以外にもAWSサポートに問い合わせできたり、自身の環境でうまくいかないことがあれば気軽に聞くことができますので、加入しておくことをお勧めします。
S3
S3自体はストレージサービスではありますが、設定によっては外部からアクセスできてしまうので注意が必要です。
基本的には以下の観点で確認したほうがいいです。
- パブリックアクセス可能にはせず、非公開設定にしておく
- 暗号化を有効化しておく
- バケットホスティングする場合はSSLオンリーの設定にしておく
VPC（セキュリティグループ）
EC2などを利用している方は絶対設定しましょう。
何も考えずにEC2インスタンスを立ち上げるとデフォルトのセキュリティグループに設定されます。
このデフォルト状態はなんでもアクセスできてしまう状態です。
セキュリティグループでよくあるファイアウォールのようにポートの制限やIPの制限を設定することができます。
要件にあわせて設定しておきましょう。
コンプライアンス
身内が悪さをしないように監視、制限、検出を目的としたものを書いていきます。
IAM
AWSを利用する上で必要になるアカウントサービスです。
複数名で作業する際はIAMを利用してアカウントを追加していきます。
ただ、IAMアカウントのパスワードが漏れて、AWS管理コンソールにログインされてしまうと自身のAWS環境で自由に操作されてしまいます。
これらの観点から必要となるポイントは以下の通りです。
- サインインをMFA（多要素認証）にする
- 各アカウントが利用できるサービスを制限する
- アクセスキー、パスワードを定期的に変更する
まず、１について説明します。
通常はユーザ名とパスワードでAWS管理コンソールにサインインできてしまいますが、それとは別に認証を実施する設定を行う形です。
MFAにはいくつか方法があります。サインイン時にメールで認証コードが送られてその認証コードで認証を行ったり、ワンタイムパスワード認証を行ったりとかです。
MFA設定をすることでパスワードが漏れたとしても、上記の認証が通らないとサインインできないのでセキュリティが高くなります。
続いて２ですが、IAMにはポリシーというものがあり、このポリシーでどのサービスが閲覧可能か更新可能かなどを細かく指定することができます。
さらにグループを利用することでAdministorator権限、Developer権限、Guest権限といった形で使用できるサービス範囲を自身で設定することができます。
上記は凝り始めると時間がかかりますが、システム管理者以外は基本的に必要なサービスだけ操作できるようにしておいたほうがいいです。
最後、３についてですが、アクセスキーとパスワードを定期的に変更することです。
特にアクセスキーは定期的に変えたほうがいいです。IAMの画面で90日を超えたものは赤色表示になります。AWS側として90日で変更することを推奨しているため、最低限そのルールに従って変更しておくのがベターです。
パスワードについてもIAMのユーザ一覧で何日間変更していないか表示されていますので、ご自身の会社のルール等に従って定期的に変更するのが望ましいです。
後、パスワードポリシーが初期状態だと6文字以上の制限だけなので、パスワードポリシーを強度なものにしておいたほうがいいです。（大文字含む、数字含むなど）
CloudTrail
IAMアカウントや作成したサービスが操作した履歴を保持するサービスです。
何も設定しなくても、3カ月間のログを確認することが可能ですが、後で追えなくなると困るのでS3にこれらのログを保存する設定を行ったほうがいいです。（証跡の作成で設定可能です）
CloudTrailを利用することで、どのアカウントがいつサインインしてどのサービスを触ったかなどを確認することができます。
Guard Duty
悪意のある操作をしていないかなどを検出してくれるサービスになります。
設定自体は有効にするか無効にするかだけなので簡単にできます。
上記、説明したCloudTrailなどのログを分析して脅威を識別して優先順位もつけてくれます。
人の目でCloudTrailのログを毎日確認するのは難しいと思いますので、セキュリティ的に不安であれば設定しておくといいです。
それでも心配な方へお伝えしたいこと
AWSのセキュリティ対策について書いてきましたが、それでも心配な方向けに書いていきます。
絶対に大丈夫というのはない
そもそも完璧に大丈夫というのはないと思ってます。
よくある質問でセキュリティ的に大丈夫なの？ということを聞かれたりしますが、何の脅威に対しての？っていつも思います。
未知の攻撃に対して、対策を行うのは相当難しいです。（無理なのではと思っています）
なので、最終的にどこかで妥協する必要があります。
とはいえ、実際に顧客のシステムのセキュリティ的にどういった対策をするか説明しないといけないこともあるかと思います。
主に非機能要件フェーズでこれらの話をするかと思うので、まずどういった脅威に対して対策を行うかを顧客と認識合わせしておくようにしましょう。
専門家に依頼するのが堅実
システムのセキュリティ診断を専門にしている会社なり部署なりに依頼するのが一番いいかと思います。
実際にシステム開発を行っているベンダー自身ではなく、第三者に入ってもらいチェックしてもらったほうが信頼性があがります。
基本的にアプリ開発している方は、セキュリティ専門で作業されていないと思うので、思い切ってプロにお願いしてしまったほうが楽で安心です。
最後に
AWSのセキュリティ対策について説明していきました。
セキュリティ対策として簡単にポイントを書きましたが、AWSのドキュメントにAWSセキュリティのベストプラクティスといった資料が存在しますので一度見て頂くほうがいいと思います。
正直なところ、突き詰めるときりがないのでどこで妥協するかが大切だと思っています。
私の考えとしては自分の手に負えないなら、プロに任せてしまったほうがいいと認識です。
AWSのサポートでも一番いいものを利用すれば、コンサルからしてもらえます。
※それなりの金額がしますが。
もし、自分の力で勉強して頑張りたいと思っている方はAWSにセキュリティの資格がありますので、AWSのセキュリティ対策の勉強がてらに目指してみてはいかがでしょうか？
amazonに本もありますので興味ある方はポチってみましょう。
コメント