年末セキュリティ点検ウィーク ☆⌒(ゝω・)vキャピ

記事タイトルとURLをコピーする
最近iPad miniの便利さに目覚めVGAケーブルも購入し、仕事もiPad miniで出来ないか常に試行錯誤している小室@福岡です。唯一残念な所はこのiPad miniはキャリア対応していないという事ぐらいですかね。

AWS Advent Calendar 2012

さて、うかつにも参加申請をしたので、記事を書きたいと思います。 AWS re:Inventの参加レポートを全部ご覧になった方は気づいたかもしれませんが、私の参加したセッションはほとんど、セキュリティ関連か、IAM関連でした。何でこんなにセキュリティとか好きなのか気になる方は忘/新年会等で聞いて頂ければ、面倒くさい感じでくどくど話をさせていただきますっ(・ω<)☆ 年末大掃除の時期なので、年末AWSセキュリティ点検ウィークを行なって清々しい気持ちで年始を無事に迎えましょう!

目次

  1. MFA(多要素認証)を有効にする
  2. AWSアカウントのアクセスキー/シークレットキー、X.509証明書を削除する
  3. 各AWSアカウント、IAMのアカウントのパスワードを強固にする
  4. ID/パスワードは適時に交換する
  5. 別のAWSアカウントとの共有はIAMで賢く行なう

用語集

  • AWSアカウント: メールアドレスとパスワードで構成される。全リソース、ログにアクセス出来る権限を持つ。最初に取得するアカウント
  • IAM: Identify and Account Management

MFA(多要素認証)を有効にする

非常に基本ですが、AWSアカウントにはMFAを有効にしましょう。MFAには専用端末、もしくはアプリ版があります。日本で使えるGoogle Authenticatorについてはこちらが参考になると思います。 AWS Virtual MFAですが、amazon.comにアカウントがあり尚かつ住所/電話番号が米国でないとダウンロードが出来ません。またダウンロード時にIPアドレスも見ているようなので、USにProxyサーバを立てる必要があります。AWS Virtual MFAは何で米国以外でダウンロード出来ないのでしょうか(何か設定方法があるのかしら) 色々試した結果AndroidのAWS Virtual MFAは日本から使う際は非常に面倒くさいので、Google Authenticator が楽でいいですね! ちなみに営業の永淵がiPhoneで認証をしたVirtual MFAを削除したらどうなるのだろうか、と検証した事があったそうなのですが、ものの見事にAWSマネージメントコンソールにログイン出来なくなり、AWSサポートに問い合わせをして助けてもらったそうです。

AWSアカウントのアクセスキー/シークレットキー、X.509証明書を削除する

最近AWSを使い始めた方は知らないかもしれませんが、昔はIAMという便利な物はありませんでした。なので、APIでAWSのリソースを触る場合は、AWSアカウント配下に(a) アクセスキー、 (b) X.509 証明書、 (c) 一対の鍵 (今で言うEC2のKey Pairs)を取得して、利用していました。 でも有り難い事にIAMが出来る様になったので、AWSアカウント配下にあるアクセスキー/シークレットキー、X.509証明書は無効にしましょう。そしてIAMを使いましょう。昔からAWSを使っている人は意外と削除を忘れている人が多いんじゃないかな、と思いました。忘れずにチェック。 さようなら、セキュリティ証明書。  

各AWSアカウント、IAMのアカウントのパスワードを強固にする

パスワードの強固になればなるほど、ユーザーからは文句が出るのが世の中の常ですが、今ではoktaなどのIAMでSSO出来るサービスがあるのでそちらを使うと覚えなくて済むのでよいのではないでしょうか。どの程度強固に出来るかというと

  • 最低限の文字数
  • 一つ以上大文字を入れる
  • 一つ以上小文字を入れる
  • 一つ以上数字を入れる
  • 一つ以上記号を入れる
  • ユーザーにパスワードを変更させる

のような選択肢があります。上記をカバーし8桁以上のパスワードにすると、ブルーフォースアタックや辞書攻撃など機械で解読するには約一千年程度かかるらしいので、これは設定しない訳には行きませんね! こんなパスワードの作り方も参考になるかもしれません。

ID/パスワードは適時に交換する

IAMではアクセスキー/シークレットキー、X.509証明書を作成、登録出来るのですが、こちらを適時に交換してセキュリティを上げる事が可能です。

Access Keyの場合

↑上記は同じ時期に作ったのであまりよい例ではありませんが、AKIAJ---GHAの方が最初に作った方だとすると、交換時期になったら、新しいアクセスキーを作成し、両方平行して利用する事が可能です。新しいキーの方に完全に移行したら、まずは無効にし、 さらに問題がなければ削除、というフローを行なえば安心ですね。X.509証明書でも同じ事が出来ます。 こちらは運用フローとかに組み込んでおくといいのではないでしょうか。更にはアプリに組み込んでおいて自動で行なえると更に良し!  

別のAWSアカウントとの共有はIAMで賢く行なう

発注をしている開発会社に、共通の開発環境を触ってもらったり、データにアクセスしてもらったりする際に、AWSのIAMのID/PasswordをZipにパスワードをかけて送る、というのもありますが、もし相手もAWSアカウントを持っているのであれば、Roleを使って簡単によりセキュアに共有しましょう。 詳細はDelegating API Access to AWS Services Using IAM Roles にあります。 IAMのページでRoleから作成します。 共有したい相手のAWSアカウント番号を入力します。 その後、権限が(1)テンプレート、(2)自動生成、(3)カスタマイズの設定を行なう事が出来ます。 テンプレート一覧

  • Administrator Access: 管理者権限を付与(全リソースの権限を付与)
  • Power User Access: ユーザーとグループの管理権限以外を除いた全ての管理者権限
  • Read Only Access: 全リソースの閲覧のみの権限
  • AWS CloudFormation Read Only Access: マネージメントコンソールから起動されたCloudFormation経由でのアクセスのみ許可
  • CloudFront Full Access: マネージメントコンソール越しにCloudFrontの管理者権限付与と、S3の一覧権限もあり
  • CloudFront Read Only Access: CloudFront配信設定と配信一覧リストを読み込む権限
  • CloudWatch Full Access: CloudWatchの全管理者権限の付与
  • CloudWatch Read Only Access: CloudWatchの読み込み権限のみ
  • AWS Direct Connect Full Access: マネージメントコンソール経由でのDirect Connectの全管理者権限
  • AWS Direct Connect Read Only Access: マネージメントコンソール経由でのDirect Connectの読み込み権限
  • Amazon DynamoDB Full Access: マネージメントコンソール経由でのDynamoDBの全管理者権限
  • Amazon DynamoDB Read Only Access: マネージメントコンソール経由でのDynamoDBの読み込み権限
  • Amazon EC2 Full Access: マネージメントコンソール経由でのEC2の全管理者権限
  • Amazon EC2 Read Only Access: マネージメントコンソール経由でのEC2の読み込み権限
  • AWS Elastic Beanstalk Full Access: Beanstalkの全権限とBeanstalkが使うリソースのアクセス(S3とEC2等)
  • AWS Elastic Beanstalk Read Only Access: Beanstalkの読み込み権限
  • Amazon ElastiCache Full Access: ElastiCacheの全管理権限
  • Amazon ElastiCache Read Only Access: ElastiCacheの読み込み権限
  • Amazon Elastic MapReduce Full Access: EMRの全管理者権限と、EMRが利用するリソースへのアクセス(S3やEC2等)
  • Amazon Elastic MapReduce Read Only Access: マネージメントコンソール経由のEMR読み込み権限
  • AWS Marketplace Read-only: AWSマーケットプレイスの情報を見る事が可能
  • AWS Marketplace Manage Subscriptions: AWSマーケットプレイスで購入、停止する権限
  • AWS Marketplace Full Access: AWSマーケットプレイスでの購入/停止権限、ソフト販売をする管理ページ、EC2アクセス管理権限
  • IAM Full Access: マネージメントコンソール経由でのIAMの全管理権限
  • IAM Read Only Access:  マネージメントコンソール経由でのIAMの読み込み権限
  • Amazon RDS Full Access: マネージメントコンソール経由でのRDSの全管理権限
  • Amazon RDS Read Only Access: マネージメントコンソール経由でのRDSの読み込み権限
  • Amazon Route 53 Full Access: マネージメントコンソール経由でのRoute53の全管理権限
  • Amazon Route 53 Read Only Access: マネージメントコンソール経由でのRoute53の読み込み権限
  • Amazon S3 Full Access: マネージメントコンソール経由での全バケットの管理権限
  • Amazon S3 Read Only Access: マネージメントコンソール経由での全バケットの読み込み権限
  • Amazon SES Full Access:マネージメントコンソール経由でのSESの管理権限
  • Amazon SES Read Only Access: マネージメントコンソール経由でのSESの読み込み権限
  • Amazon SNS Full Access: マネージメントコンソール経由でのSNSの管理権限
  • Amazon SNS Read Only Access: マネージメントコンソール経由でのSNSの読み込み権限
  • Amazon SQS Full Access: マネージメントコンソール経由でのSQSの管理権限
  • Amazon SQS Read Only Access: マネージメントコンソール経由でのSQSの読み込み権限
  • AWS Storage Gateway Full Access: マネージメントコンソール経由でのストレージゲートウェイの管理権限
  • AWS Storage Gateway Read Only Access: マネージメントコンソール経由でのストレージゲートウェイの読み込み権限
  • AWS Support Access: AWSサポートセンターへのアクセス権限
  • Amazon VPC Full Access: マネージメントコンソール経由でのVPCの管理権限
  • Amazon VPC Read Only Access: マネージメントコンソール経由でのVPCの読み込み権限
  • AWS Account Activity Access: アカウントアクティビティページへのアクセス権限
  • AWS Account Usage Report Access: 利用レポートへのアクセス権限

テンプレートを組み合わせる事をもカスタマイズする事も可能なので、うまく組み合わせて他のAWSアカウントユーザーとリソースの共有をしたいですね。

まとめ

全てはIAMに統合して、定期的に見直しを行なってより権限を少なくするように運用すると、漏洩などの可能性が減りよいのではないでしょうか。 AWSがセキュリティにしっかりしているとしても、利用者側がそれらをセキュアに使わなければ意味がありません。 物理サーバ側もセキュアに、仮想サーバ側もセキュアに、クラウドを便利に使って行きましょう〜!

年末大掃除は大変ですが、年始は清々しい気持ちで迎えたいですよね!皆さま、セキュアに、よいお年をお過ごしください。