Copyright © 2018 EXA CORPORATION
セキュリティに関する考え方
本システムは、秘匿性の高いデータを持っていない。また、社員が通常業務を行う上で
ミッションクリティカルなものではないため、以下の観点で基本的な対策をとることとした。
Web アプリでのユーザ認証
ユーザが社内の共通認証基盤でログイン出来るように Google の OpenID Connect を利用してユーザを認証する
項番 内容
① 利用するWebページを取得
② 社内の共通認証基盤でログインし、IDトークンを取得する
③ IDトークンからユーザの認証情報を生成し返却する
④ ③で取得した認証情報を付与してAPIへリクエストを送信する
⑤ 認証情報を検証し、認可されていればLambdaを実行する
認証フロー
Copyright © 2018 EXA CORPORATION
チャットボットのアクセス制御
Hangouts Chat
Google Apps Script Google Cloud
Platforms
CloudFront
WAF
IF
キーの送信①
IF
キーの存在チェックAPI
キーの付与②
API
キーの存在チェックブロック項目 手法
①作成したプログラム以外からのアクセス
WAF
を使用してリクエストにIF
キーが存在するかをチェックする②API Gateway への直接アクセス
Cloud Front
を使用してリクエストにAPI
キーを付与し、API Gatewayで存在をチェックする
API Gateway Lambda DynamoDB
研修実績管理システムのプログラム以外から ボット API を利用できないようにする
６．アクセス制御と認証
Web アプリのアクセス制御
CloudFront
API Gateway Lambda
WAF
DynamoDB ブラウザ
S3
②
Cloud Front
経由チェック①
IP
アドレスチェック③認証チェック
ブロック項目 手法
①社外
IPからのアクセス WAFを使用して、 IPアドレスのチェックする
②
S3
への直接アクセスCloudFront
経由のアクセスかをS3
でチェックする③未認証ユーザの
API Gatewayへのアクセス API Gatewayでユーザの認証をチェックする
社員以外の人が Web アプリにアクセス出来ないようにする
Copyright © 2018 EXA CORPORATION
個人情報の保護
IF
チャットボットでの
ID生成箇所
Webアプリでの ID生成箇所
インターフェースのイベントが発火した際に渡される情報には、実行したユー ザの情報が含まれている。
その情報の一つにメールアドレスがあるためそれを利用する。
ID
トークン を検証する際にユーザ情報を取得す ることが出来る。その情報の一つにメールアドレスがあるためそれを利用する。
• 社員の個人情報をAWSで保持しない設計とした
• 社員を特定するキーとなるようなプログラム上必要な情報はユーザのメールアド レスをハッシュ化した物を利用した
• なりすましを防ぐためにユーザのメールアドレスはユーザが入力したものではな く、サーバー側でGoogle から取得して生成した
６．アクセス制御と認証
目次
1. はじめに
2. 研修実績管理システムの概要 3. AWS Lambda を利用した開発 4. チャットボットの開発
5. Web アプリケーションの開発 6. アクセス制御と認証
7. CI/CD 実現のためのポイント 8. おわりに
※本資料に記載されているロゴ、システム名称、 企業名称、製品名称は各社の登録商標または商標です。
Copyright © 2018 EXA CORPORATION
CI/CD 環境が何故必要か
開発手法としてアジャイル開発を取る事に決定
スプリント毎にフィードバックをもらうため、早く リリースできる環境を整える必要がある
CI/CD 環境の構築が必要不可欠！
７．CI/CD実現のためのポイント
• ソースコードをコミットするだけでパイプラインが走る様にする
– CLIからアップロードする事も可能だが、開発者のローカルPCの
環境構築が煩雑
• クラウド上のサービスのみを使って CI/CD 環境を作る
– 自前で CI サーバは立てない
CI/CD 環境構築時の考慮点
サーバを直接参照できない
war を作って scp でアプリサーバにコピーして ... は不可能
Copyright © 2018 EXA CORPORATION
CI/CD プロセスの概略図
７．CI/CD実現のためのポイント
Build
• AWS リソース
– CloudFormation テンプレートをデプロイ可能 形式に変換
• Web アプリクライアント
– S3 の Web アプリ配信用バケットにクライアント
リソース (HTML + js) をアップロード
Copyright © 2018 EXA CORPORATION
Deploy
• AWS リソース
– テンプレートを基に各種サービスを デプロイ
• Lambda 関数
• DynamoDB のテーブル
• API
• Web アプリクライアント
– 特になし
※ デプロイで使用しているサービスの都合上、
Web
アプリク ラ イアントはBuildプロセスにてデプロイ７．CI/CD実現のためのポイント
Test
• 各種テストを実行
• テスト実行後、各種テストレ
ポートと Web アプリの ITb の
実行中に撮られたスクリーン
ショットを S3 のバケットに保
存
Copyright © 2018 EXA CORPORATION
複数環境へのデプロイ
• 本番環境へ影響を与えずに Staging 環境を自動構築できる様にし たい
→ 実開発前にブランチモデルの策定
• 本番環境と Staging 環境で構成が異なってしまう事を避けるため CloudFormation テンプレートファイルは 1 つにしたい
→ CloudFormation パラメータ・ Lambda 環境変数を活用
７．CI/CD実現のためのポイント
本番機とは別に検証用に Staging 環境が必要
実開発前にブランチモデルの策定
bugfix master
release develop
feature branches
ソースコードの構成管理として
Git-flow というブランチモデルを使用する事を策定した master
のソースコードに変更があると
本番環境用
Pipelineが実行
developのソースコードに
変更があるとStaging
環境用Pipeline
が実行Copyright © 2018 EXA CORPORATION
CloudFormation パラメータ・ Lambda 環境変数を活用
Regiser: # 登録ロジックLambdaの定義
FunctionName: !Sub ‘tr_${EnvName}_register’
...
Environment:
RESULT_TABLE: !Sub ‘tr_${EnvName}_result’
...
CloudFormation Template Staging
環境用CodePipeline
設定画面(CloudFormationの設定)
Lambda
関数名環境変数
７．CI/CD実現のためのポイント
Web アプリクライアントの複数環境対応
同じソースコードで Pipeline 上の Build プロセス時に特定の箇所を 置換できる様にしたい
Staging
用Pipeline
本番用
Pipeline
...
let url = API_ENDPOINT; ...
org
stg
...
let url =[Staging用URL];
...
Build Deploy Test
prod ...let url =[本番用URL];
...
Build Deploy