FinTech X Security-JAWS 勉強会#01レポート #secjaws #finsecjaws01

臼田佳祐

2017.06.16

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは、臼田です。

FINOLAB 様とSecurity JAWSのコラボレーション企画の勉強会が開催されましたのでレポート致します。

FinTech X Security-JAWS 勉強会#01 | ATND

セッションレポート

開始挨拶: 金融機関におけるシステムリスク管理とセキュリティ対策の考え方

みずほフィナンシャルグループ大久保光伸様

システムリスク管理

リスクの種類
- システムリスク
- 事務リスク
- 法務リスク
- 人的リスク
- 有形資産リスク
- 規制・制度変更リスク
- レピュテーショナルリスク
新規取引先の確認をどうするか
- ISO27001、PCI DSS、SOC1/2、監査機関による定期検査とレポートを参考にする
- 金融業界における導入事例が参照されるケースが多い
- 行員による実地検査を行う場合もある
評価スキームの概念
- 基本方針
  - システムリスク
  - 利用者保護(情報管理態勢)
  - などなど
- 対策基準
  - FISC安全対策基準(金融機関向けAWS対応セキュリティリファレンス)
- 実施手順
  - 各種チェックリスト
AWS上での内部不正対策
- IAM
  - 接続元IPの制限
  - 多要素認証(MFA)
- AWS Config
  - 変更管理
- Cloud Trail
  - 操作ログの取得
AWS上でのデータ統制
- IAM
  - 操作権限の管理
- 暗号化オプション
  - EBS、S3、Glacierの暗号化オプション
- Key Management Service
  - 鍵をユーザサイドで管理
- Cloud Trail
  - 操作ログを取得
セキュリティ診断
- Trusted Advisor
  - パーミッションを確認してアプリケーションセキュリティを向上
  - 不要リソースやアイドル状態のリソースの除外

APIセキュリティ対策

JBA中間的整理（セキュリティ原則）
- API接続先の適格性
- 外部からの不正アクセス対策
- 内部からの不正アクセス対策
- 不正アクセス発生時の対応
- 継続的な改善・見直し、高度化
JBA中間的整理（利用者保護原則）
- API接続先の適格性
- 説明・表示、同意取得
- 不正アクセスの未然防止
- 被害発生・拡大の未然防止
- 利用者に対する責任・保障
オープン API のあり方に関する検討会報告書 - 全国銀行協会 https://www.zenginkyo.or.jp/fileadmin/res/news/news290316_2.pdf
安全で便利な生体認証FinTech「手ぶら決済」の実力：PRESIDENT Online - プレジデント http://president.jp/articles/-/20255
Fujitsu BankのFIDOをつかった振込操作のDEMO

Session 1: 金融機関/FintechにおけるAWS活用とセキュリティ

Amazon Web Services Japan 瀧澤与一様

主にセキュリティバイデザインについて話したい
日本の金融も去ることながら、海外銀行での採用も多い
FinTechでは94%の企業で利用されている！
様々なFinTechサービスで利用されている
- PEM
- 決済・送金
- レンディング
- 証券取引・試算運用
- 保険
- などなど
事例と採用理由
- コイニー株式会社
  - PCIDSS完全準拠した
- freee株式会社
  - セキュリティ
  - 運用コスト最適化
- 三菱東京UFJ銀行
  - 一個一個のサービスのSLAやリスクなどを検証し、サービスごとに利用を許可していった
- ソニー銀行
  - 基幹系以外のAWS移行が概ね完了(見込み)
  - 環境系も検討
- SOMPOホールディングス
  - 最先端アーキテクチャの採用
  - 柔軟性とスピード
  - セキュリティランクの高いデータの取扱
- Capital One

Security by Design

AWSでは自動化が容易なので、セキュリティ管理を自動化し、監査を合理化したほうがいい
セキュリティバイデザインで実現できること
- 許可されていないユーザが変更しない
設計の原則
- 手作業を排除して自動化出来るところがないか検討
- セキュリティフレームワークを組み込む
- 全レイヤーで構築する
- 障害を前提とした設計
- 自動修復を実装する
- 並行して考える
- 違反の計画
導入のステップ
- 要件を把握
- 構築
- テンプレート(Cloud Formation等)の使用
- 検証
デモ
- instanceをセキュリティグループ全開放で起動したら止める
- CloudWatchからLambdaで処理

Session2: Building Security In で開発者によるセキュリティの確保を目指す(仮)

アスタリスクリサーチ池田克巳様

システムリスクの原因の85%は構築段階で発生している
ここを強化しよう！
AWSならネットワーク設定やSecurity Groupでインフラ的には大丈夫
アプリケーションレイヤーではOWASPの考え方を利用してセキュリティを確保しよう
特にOWASP Top 10をチェックしよう
OWASP TOP 10はProactive Controlsも参考にしている
OWASP以外にはIEEEのAvoiding the Top 10 Software Security Design Flawsもある

システムの品質と安全性の向上のためにシフトレフト(本題)

実現するには
- 早期に繰り返しテスト(下に行くほど前段階 = シフトレフト)
  - ペネトレーションテスト
  - コードレビュー
  - トレーニング
SecureAssistを紹介
- コードレビューのフェーズで利用
- スペルチェッカーのような使いやすさで開発環境にセキュアコーディング手法を浸透
- IDEを拡張して利用
- デモ
  - Eclipseでデモ
  - コードのエラーのようにIssueとしてSQLiを指摘している
  - Issueをクリックすると該当コードと参考になるガイダンスを表示
  - 開いているコードだけではなく、一括でプロジェクトの問題を確認することも出来る
- 対応言語
- 開発言語としては、Java、.NET(ドットネット)、PHP、そしてそれぞれの設定ファイルを調べることができます。

まとめ

シフトレフトはキャッチーなのでぜひシフトレフトと言おう！
(ポーズも取ろう！)

Session3: PayPalとセキュリティの関係について

PayPal 岡村純一様

PayPalとセキュリティの関係について from Junichi Okamura

PayPalの仕組み
- 買い手と売り手の間で決済を安全に行う
今日のお話
FintechのパイオニアであるPauPalと3つのセキュリティキーワード
- PCIDSS
- Tokenization
- Anti-Fraud
PCIDSS
- 国際カードブランドが定めたセキュリティ基準
- ISMSと似た基準だがより範囲が狭くかつ深い(厳しい)
- カード情報を伝達・保存する行者は取得しないとカード決済は導入できない
- 扱うデータやその方法で取得するランクがある
- 維持に多額のコストがかかる
- バージョンがある
- 具体的な内容
  - 公式ドキュメント
  - PCI DSSv3.0のSAQ A-EPとAは何が違うのか
- 恩恵
  - 情報漏えいの防止
  - 信頼の獲得
Tokenization
- カード情報などの機密情報を直接やり取りせずトークンで行う
- Tokenizationを使った新しいSDK Braintree SDK
  - 日本語情報準備中
  - サンプルあるよ！
  - 技術的特徴
    - Client Sideにほとんどの実装を寄せている
    - Tokenizationによってセキュリティ担保とサーバ処理の独立
  - 2つのTokenと1つのNonce(ワンタイムトークン)を使って行う
Anti-Fraud
- 詐欺防止の意味合い
- PauPalでは世界規模でセキュリティアップグレード計画を実施
  - APIやその他通信の強制アップグレード
    - TLS1.2 HTTP 1.1へのアップグレード
    - SSL証明書のアップグレード
    - 通知確認用URLなどすべての接続のHTTPサポート終了
- PayPalの不正対策
  - システム検知とオペレーションのハイブリッドで24/365対応
    - イメージはこちらを参照
  - 売り手保護制度
  - 買い手もあるよ
ユーザグループPPUGあるよ
- イベントあるよ

Session4:「金融API向けOAuth」にみるOAuthプロファイリングの実際

NRIセキュアテクノロジーズ工藤達雄様

OAuthとは
APIアクセス(フルオープン)
- APIアクセスをクライアントのクレデンシャルで制限する
  - 継続して許可するのは不都合
  - トークン1つでずっと許可するのか等
- クレデンシャルを元に付与したトークンでAPIアクセス制限する
  - 認可サーバでアクセストークンを提供する
- リソースオーナーのID/パスワードを使ってAPIアクセスを制限したい
  - リソースオーナーパスワードクレデンシャルグランドを使用する(非推奨)
  - クライアントがサードパーティの場合信用出来ないので
- 認可コードを元に付与したトークンでAPIアクセスを制限する(一番良く使われる)
  - 認可コードをもってアクセストークンを提供する
  - AWSサービスを利用して構築も可能
  - Amazon API Gateway with カスタムオーソライザーと外部認可サーバによる構成例
  - API GatewayとLambdaとサードパーティ認可サーバ（AuthleteとかHydoraとかWSO2とか）で可能
  - Amazon API Gateway の Custom Authorizer を使い、OAuth アクセストークンで API を保護する
決め事を色々やる必要がある
- クライアントのリダイレクションエンドポイント(cont.)
  - 仕様上クライアントリダイレクションエンドポイントは認可サーバに事前登録すべき(SHOULD)
- 認可リクエストのstateパラメータ
  - クライアントが認可リクエストのパラメータとして設定する値
- トークンリクエストにおけるクライアント認証
金融分野のOAuthの標準化が必要
- 解釈・実装方法が様々あるので標準化が必要
- OpenID FoundationのFAPI WGで進めている