こんにちは、cloudpack の ひろかず です。

2015年1月22日開催のSecure AWS Users Meetup #1に幸運にも参加することができたので、カジュアルに一筆書きます。

ダイニング・キッチンのような会場でリラックスムードでの会でした。

お品書き

  1. How to secure your AWS API
  2. Slackで作る社内SOC
  3. IAM ユーザー管理：awscliを用いたユーザー管理とIDフェデレーションの比較
  4. [LT]セキュアだ！freeeだ！
  5. [LT]Attack on AWS, ec2 + honeypot
  6. [LT]セキュリティの設定、どこまでやってますか？
  7. [LT]IAMでの権限設定をひたすらがんばっている話

1.How to secure your AWS API

AWS上の侵入検知/防御

  • WAFを入れてもロジックバグは防げない。(脆弱性診断が必須)
  • 考え方はオンプレと変わらない。(NWが触れないくらい)
  • AWSの操作はAPIでできるので、とにかくAPIを守る。APIを触られないことが前提。
  • 事故事例：bitcoin採掘(AccessKey/Secretkeyがgitから漏れる)

ソリューション

  • IAMで権限絞る(rootアカウントはMFAにして封印する)
  • 標準ポリシー(必要最低限)は、グループ単位で作成する。
  • コンソールユーザにはMFA必須にしたいけどポリシーでは絞れないので、Credential ReportでMFA設定していない人を検出
  • アクセスキー管理は、envchainを使うといい。(Macユーザ向け)
  • ポリシーの変更管理は、miamを使うといい(ポリシーをtxt管理：gitっぽく)

ポイント

  • 気付くためには、APIコールのログを取る => cloudtrail
  • ログはS3に入るけど、MFA Deleteで縛る。
  • 見るポイントは「失敗の兆候」
  • Conditionは、時間帯とか細かく使えるけど、使いすぎると複雑化する。

2.Slackで作る社内SOC

  • SOCとは、Security Operation Centerのこと。
  • 各社扱っているものが違うので、ログ分析をアウトソースするのもポイントがズレる。
  • 社内でログ監査しようにも体制がない。

ソリューション

  • slackをSOC基盤にする。(みんな見れるし)
  • ログをfuletdで集めてSlackに流す。(pluginある)
  • 不正アクセスポイントは小型PCで(FlashAir x 電子制御盤)で常時監視(リアルタイムでslackに投稿)
  • 入退室管理もslackに投稿

ポイント

  • /var/log/secure見るのは鉄則(ログイン失敗は明らかに変)
  • tail -f 程ではないが、リアルタイム性があるのがいい。
  • slackに全部出し

3.IAM ユーザー管理：awscliを用いたユーザー管理とIDフェデレーションの比較

ポイント

  • ログ収集・解析は、CloudTrail>SNS>SQS
  • NessusでAWSセキュリティベストプラクティス検査機能がある($1,200)
  • PCIDSSの認定スキャナ
  • IAMの強権限を使って設定をチェックしてる。

LT1.セキュアだ！freeeだ！

ポイント

  • Security MonkyでIAM監視
  • Google auth proxyいいかも

LT2.Attack on AWS, ec2 + honeypot

ポイント

  • 攻撃ポートは、9200,3128,3389,22、他には2222やXX22は人気
  • shellshockは80、8080(NAS脆弱性)が人気

LT3.セキュリティの設定、どこまでやってますか？

ポイント

  • outboundは制限したほうがいい(iptables,nacl：shellshockはこれで被害制限)

LT4.IAMでの権限設定をひたすらがんばっている話

ポイント

  • IAMポリシーの * は敵
  • conditionでIPとregion縛る

雑感

お寿司おいしかったです。

元記事はこちらです。
「Secure AWS Users Meetup #1に参加してみた」