2015年1月22日開催のSecure AWS Users Meetup #1に幸運にも参加することができたので、カジュアルに一筆書きます。
ダイニング・キッチンのような会場でリラックスムードでの会でした。
お品書き
- How to secure your AWS API
- Slackで作る社内SOC
- IAM ユーザー管理：awscliを用いたユーザー管理とIDフェデレーションの比較
- [LT]セキュアだ！freeeだ！
- [LT]Attack on AWS, ec2 + honeypot
- [LT]セキュリティの設定、どこまでやってますか？
- [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に参加してみた」
