Sign in
aws

Security-JAWS #3

Lorentzca

• 5 min read
Security-JAWS #3

Security-JAWSに参加してきたメモ！(Security-JAWSはいつも速攻埋まるけどたまたま参加できた)

流れ。

  • 「CloudHSMって結局なに？ハードウェアが必要なわけ」
  • 「AWS IAMとOpenAMを連携してアカウント管理を効率化してみた」
  • 「Amazon Inspectorを補完する - VulsとOWASP Dependency-Checkを組み合わせてプログラミング言語ライブラリの脆弱性スキャン結果を日本語化、Slack通知できるようにしてみた」
  • LT「EnigmaによるPersonal Data Storeの実現可能性について」
  • LT「AWSのセキュリティホワイトペーパーまとめ」

「CloudHSMって結局なに？ハードウェアが必要なわけ」

CloudHSM自体この会ではじめて知ったし、事前にググってもよくわからなかったけれどなんとなくCloudHSMについて分かった気がする。

CloudHSMとは

  • CloudHSM(Hardware Security Module、暗号モジュール)とはデータの暗号化を提供するAWSのサービス
  • 暗号化のためのキー生成と、その管理システムを提供する
  • 類似するAWSサービスにKMSがある
  • KMSとの違いとして、CloudHSMは「FIPS140-2」、「PKCS #11」という規格を満たしている事があげられる
  • HSM自体はAWSの独自用語ではなく、一般的な用語

FIPS140-2とは

  • 米国の暗号モジュールに対するセキュリティの規格の1つ
  • セキュリティレベルの高さに応じて4レベルまで存在する
    • レベル1: 甚だしくセキュリティの欠如がないこと
    • レベル2: レベル1を満たしかつ物理的な改竄の痕跡を残すこと
    • レベル3: レベル2を満たしかつ物理的な改ざんへの耐性があること
    • レベル4: 環境条件を変動させての攻撃に対して頑健であること(?)
  • レベル4は軍用とかで、商品でレベル4取得しているものは無いらしい(厳しすぎて実用に耐えない)
  • AWS CloudHSMはレベル2認定
  • 国内では例えば政府機関やクレジットカード会社で導入されている

そもそも暗号モジュールとは

  • 暗号処理専用のハードウェア
  • 普通os上のソフトウェアで鍵生成したり複合したりするが、その処理を専門にしているハードウェア
  • 暗号化の鍵とデータがハードウェア内にあり、鍵はハードウェア外に持ち出せない(そもそも外部に出力する機能自体が無い)
  • アプリケーションは暗号化したいデータをHSMに投げ、暗号化された結果を得る
  • 攻撃者はHSMに侵入できない(そのような機構がないため)のでせいぜい暗号化されたデータを得られるくらいで、最悪の事態を防ぐことが出来る

PKCS #11とは

  • HSMへ通信して公開鍵を得るためのインターフェースを定義する規格(で合ってるのかな…ちょっと自信ない)
  • 一般的な規格で、SSLなど広く使われている

ユースケース

いつCloudHSMが必要になるかというと、以下のような場合はKMSではなくCloudHSMを使うと良いらしい。

  • 100opsを超えるような暗号化処理が要求される場合
  • 非常に厳しいセキュリティ水準が要求される場合
  • PKCS #11と連携したアプリケーションを作りたい場合

CloudHSMを使いたい場合は連絡すれば試用期間付きで試せるとのこと！

感想

セキュリティ規格周りの話が少し難しかった(元々詳しくないのもあり)。セキュリティ要件を守るためにデータセンターから移行できない場合などは、このCloudHSMを使うことで要件をクリア出来る場合もあるらしい。超セキュリティが求められるようなサービスを立ち上げたい場合に敷居が下がりそう。

もしくは個人用途として、自分の黒歴史ノートを安全に保管するためにFIPS140-2規格を満たした堅牢な暗号化モジュールによって暗号化することを検討してみてはいかがでしょうか。

「AWS IAMとOpenAMを連携してアカウント管理を効率化してみた」

OpenAMという認証基盤と、IAMをうまくつなげるという話だった。以下の記事の1〜4回にすごく詳しく書いてあって、発表内容的にはこの第4回目に当たる内容だった。

フェデレーション、フェデレーションブローカーという言葉が聞き慣れない言葉だったがだいたい以下のようなイメージ。

人の出入りがあるたびにアカウントを発行／停止するのが苦痛だったのでこのような仕組みを導入したとのこと。

感想

認証基盤は構築すること自体が結構大変そう…。でもある程度規模が大きくなるとその大変さを超えるメリットがありそうだと思いました。

私もアカウント発行作業は何度もしたことがありますが、間違えて不要な権限付与しないかとか、パスワードの連絡方法とか、別の人にアカウント発行メールしちゃわないかとか妙な緊張感があるんですよね…。頻度が多いと結構辛みのある作業だったりする。

「Amazon Inspectorを補完する - VulsとOWASP Dependency-Checkを組み合わせてプログラミング言語ライブラリの脆弱性スキャン結果を日本語化、Slack通知できるようにしてみた」

発表資料は以下！！

感想

Vulsの裏話的な部分が聞けたのが良かった。

  • Vulsは会社から期間をもらって作った
  • 当初は会社のサービスとして売り出すことも考えたが、OSSとして成長させたいという思いと、良いOSSを出すこと自体が会社のvalueにもなるということでOSSとして出した
  • 複数のOS、ミドルウェアからなる大量のサーバ管理をした経験から、それらの脆弱性情報を追うのが大変すぎて自動化しようと思ったのがきっかけ

また、モヒカンというコミュニティについて知った！入った！

LT「EnigmaによるPersonal Data Storeの実現可能性について」

Enigmaというアカデミックなプロダクトの紹介。

ビットコインで有名な、ブロックチェーンを利用した分散システムで、入出力を暗号化した形で演算リソースを提供できるみたいなプロダクトらしい…(な、何を言っt)。

日本語の解説と言うか概略の紹介みたいな記事もいくつか有った。

どんな形のサービスが実現できるのかあんまりよくわかってないけど、セキュアなメールサーバが作れたりすんのかな？

LT「AWSのセキュリティホワイトペーパーまとめ」

AWSはいろんなニーズに合わせたホワイトペーパーを用意していて、企業でAWSのサービスを導入する際の判断材料として便利みたいな話。

日本語のホワイトペーパーで、表のNo.(ナンバー)の部分がいいえと誤訳されていて会場爆笑。現在はもちろん修正されている。ちなみにいいえ、と書いてある部分は一箇所だけで、それはユーザーがAWSのデータセンターを訪問できるか、という部分。

全体の感想

セキュリティ周りは全体的にアカデミックな成分が多い気がする。難しさ、とっつきにくさを感じがちだけど、基本的なレベルでいいので暗号化のアルゴリズムの話などを知っておくと、何の話がされているかわかるようになって楽しそう。

結城さんの本読む。

参考リンク

CloudHSM周り

認証基盤周り

vuls

モヒカン

enigma

AWSホワイトペーパー

Sign up for more like this.

Enter your email
Subscribe