まめ畑

ゆるゆると書いていきます

Secure AWS Users Meetup #1に行ってきた

AWS Security

AWS上でのセキュリティの現場の声が聞ける、Secure AWS Users Meetup #1に参加してきました。 http://connpass.com/event/11019/

セキュリティというところで、現場のシビアな実情が垣間見えて非常に参考になりました。セキュリティを日々どう守るかとかAWS上でどう安全な環境を作るかという視点は今後もっと大切になると感じました。

様々な要望やシステムを守るためにAWSにまだまだ足りない物事や、AWSの勉強会では普段聞けない話が続々とでてかなりハイレベルな勉強会でした！要望などは本当に伝えたいと思います！

キーワードは、認証情報の管理の仕方、しやすさだと感じました。運営の皆様、発表された皆様、ありがとうございました！

次回もあるということで楽しみです！

メインセッション

@kani_b (Cookpad): How to secure your AWS API

  • IAMユーザ 250くらい
  • AWSではユーザ側とAWS側でセキュリティを守るべき分界点がある
  • ユーザ側の世界は主にEC2インスタンスの話
    • 基本的な考え方はAWSだからというところが少ない
    • もちろん、ミラーポートやIPS/IDSなど出来ない事もある
  • AWSは全リソースがAPIで提供されている
    • APIを守らないといけない
    • EC2やRouteテーブルなどを全削除やデータの引き出しなど
    • S3やEBSのSSEはAPIにアクセスされない事が前提。つまりAPIにアクセスさせない事が重要
  • 事故事例
    • GithubなどでKeyなどがPushされてマイニングされたりする
    • API key抜かれて乗っ取られてデータ全削除
  • まずすること
    • 権限の分解・最小化 (IAMのこと)
  • rootアカウントはリボーク
    • MFAの有効化
  • IAM User / Role
    • 業務フローに合わせて
    • MFA / Instance Role
  • MFA
    • MC使ってるユーザはMFA必須
    • APIだけのユーザはパスワードなくす
    • 全ユーザMFA必須に強制する仕組みがAWSにはまだない
    • Credential ReportでMFAの有効の有無を確認して、コミュニケーションで解決
  • アクセスキーの管理
    • bashrcなどに書きがち
    • Macならenvchainに入れる
    • アクセスキーの管理は課題
    • 権限は必要最低限のグループを作って、スタックしてユーザに割り当てていく
  • ポリシーの問題点
    • ポリシー数が増加すると見通しが悪い
    • 変更履歴を管理したい (gitぽくやりたい)
    • miamというツール
    • GHEで権限のレビュー
  • Instance Role
    • コードにkeyを埋め込まないように
    • instanceに起動時にしか割り当てられない
    • OSにアクセスされるとKey取られる！
  • CloudTrailやAWS Config
    • ログを丁重に扱う
    • 改ざんや削除されないように
    • S3に配送されるのでMFA Delete
    • 監査用ユーザ以外からアクセスされないように
    • 別のアカウントに切り出す(監査用のアカウントつくる・バケットポリシーを移譲)
  • ログを解析する
  • まとめ
    • やるべきことはAWSだからといって変わらない
    • ログは丁重に扱う
    • APIにアクセスするKeyが色んな所で使われる
  • AWSを信頼して任せる気持ちが必要
    • ホワイトペーパーなどをよんだり
    • やることはやる
  • Security on AWS
    • アグレッシブに動きやすい
    • サーバのアップデートなどが行い易い

@sowawa (WebPay): Slackで作る社内SOC

  • PCIDSSv3 レベル1準拠 (on AWS!)
  • SOC = Securty Operation Center
  • 24/7で監視
  • リアルタイム監視が必要なものはIDS/IPSだけではない
    • 入室管理
    • CI
    • デプロイ
    • 不正AP
  • めちゃくちゃ運用大変/特にスタートアップ
    • 開発・運用で24/7の体制をつくる
    • そこで、SlackをSOC基盤にする
    • Slackはみんなが生活する場だからみんながログを見ることが大事
  • DevOps的にセキュリティチェックを行う
  • DMZでfluentdで集めてSlackにながず
    • PCIDSSの要件として、DMZを通してしかInternetにしか通信しちゃだめ
  • 色んなログあるよ
    • /var/log/secure (なんか変なことしてるのがわかる/想定外のOPとか)
  • Webpayはssh 2FA
  • 不正APの検知
    • 四半期に1回とか決まってるけどそんなのだめ
    • 小さいPCを設置してAPを常に監視
  • 入室管理
    • 入退室をリアルタイムに監視
  • 見える化することはそれだけでセキュリティに大事
  • SOC
    • O = Operation
    • Security meets ops
  • セキュリティは運用指定ことが大事
    • 組織は常に変わっていくから今は何をしていくべきかを考える
    • 自分で出来ないことは他の人に手伝ってもらうのが大事
    • 見える化する事による抑止力

野渡さん (CyberAgent): IAM ユーザー管理：awscliを用いたユーザー管理とIDフェデレーションの比較

  • プロジェクト毎にAWSアカウントを用意
  • 完全な集中管理は行わない
    • 開発者を縛りすぎない
  • 全てのユーザに一意なIDを割り当てる
  • 両極なことを実現しないといけない
    • 既存のディレクトリと連携するか
    • private cloudやオンプレ環境で培った
  • VPC peer
  • CloudTrailのログは共通環境のS3バケットに転送
  • SAML連携
  • MFA無効のユーザにメールを送るなど
    • ログインプロファイル外す
  • いけてないところ
    • AWSアカウント毎にアカウントが別々になる (トークンいっぱい)
    • 別AWSアカウントのMCを使うときに都度ログアウト・ログインをやらないといけない
  • CloudTrailで出したログの解析・解析・アラート
    • CloudTrail->SNS->SQS->Splunk
  • Trusted Adviserを有効活用したい
  • Messusの有料の買うと、AWSのセキュリティベストプラクティスのチェックをしてくれる

LT

@xga : セキュアだ！freeeだ！

  • secure!
  • 200instances
  • SG設計
  • 2FA必須
  • 攻撃検知・脆弱性検査
  • SGが増えると管理が大変
    • 1 instance 5SGなのが大変
  • SGの棚卸し
  • アカウントID/PASSの扱い
    • IAMの手動管理
  • policy simurator便利
  • アプリケーションに脆弱性が会った時の対応
  • freeeは今までセキュリティインシデントがない
  • Security Monkey使ってみたい
  • Google Auth Proxy

@m_mizutani : Attack on AWS, ec2 + honeypot

  • ハニーポットを運営してみた
  • 超低インタラクションハニーポット
  • EC2にmonitor用のEIPを付与
  • 9200番ポートが突出
    • 基本は22 や proxyなどなど

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

  • 現場感あるアンケート満載！
  • SGで行った制限をiptablesでも行う方が意外と多いのが印象的でした

宮崎さん : IAMでの権限設定をひたすらがんばっている話

  • 全てのアカウントでIAMを使ってる
  • がっちり権限を制限している
  • 敵は * (e.g. ec2:*)
  • IAM運用のbest practiceをぜひ知りたい！