nttドコモの aws 開発ガイドラインとセキュリティデザインパ …€¦ ·...

© 2015 NTT DOCOMO, INC. All rights reserved.

NTTドコモの AWS 開発ガイドラインとセキュリティデザインパターン事例

～「ドコモクラウドパッケージ」が誕生するまで～

6/3/2015 栄藤　稔、@mickbean

1

© 2015 NTT DOCOMO, INC. All rights reserved. 2

AWS Summit Tokyo ‘15での発見

1. ポリシーと統制を伴ったベンダー非依存の体制

2. アジリティな開発体制

→ニューノーマル（当たり前）

クラウドネイティブを前提とした


Hardware v.s. Software

長崎社長：「我々はインフラをソフトウェア化するためにAWSを作った」


シェアリングできるデータセンター

プログラミングできるデータセンター

従来のサーバープログラミング

“Cloud Native”なプログラミング

“Cloud 1.0” v.s. “Cloud 2.0” coined by M.E.


産業のソフトウェア化によっておこること

5

• 知の共有

例：マーケットプレイスの出現。

• 新しい事業構造への転換

新しい企業関バリューチェーンの登場。→APIエコノミーの出現。　


Moved to AWS (2012)

Moved to AWS (2014)

ミッションクリティカルシステム

Webサービスシステム

業務系システム


大組織において複数プロジェクトで AWSを利用していると

• 内製ならまだしも外注文化では • 設計手法はバラバラ。 • セキュリティ対策もバラバラ。

• コスト最適化もバラバラ。

7


コスト可視化ツール：多数部署の利用が見て取れます

8

RIの有効利用度表示 • 有効なRI数 • RI利用数 • RI利用率 • RI余剰数

時系列でのコスト表示 • 利用料表示 • 利用台数表示 • 利用アカウント別 • 利用サービス別 • 日付指定 • 円換算（為替反映） • 1時間毎/1日毎 • リザーブド(RI)指定 • 利用サービス絞込 • 利用AZ絞込

表示形式 • 利用アカウント別 • 利用サービス別 • 日付指定 • 1時間/1日毎 • リザーブド(RI)指定 • AZ • インスタンスタイプ


システム・インテグレータでは解決できない問題＝クラウドを使うユーザ企業として解決すべき問題。

9

• クラウドを使う上での内部統制

• セキュリティポリシーの制定

• クラウド利用時のシステム構築の注意点

• クラウド利用におけるコスト管理方法や、セキュリティ管理


Cloud2.0 設計・構築のポイント　

10

● Design for failureあらゆるものはいつでも故障する前提で設計する

● コンポーネントの疎結合化コンポーネントを独⽴立立させ，ブラックボックス化する

● スケーラブルな構成伸縮⾃自在性があり，再起動が可能な構成にする

● 全レイヤでのセキュリティAWSとの責任分担モデルを理理解し，全てをAWSに任せない

● 並列列処理理の実装アプリケーションやバッチ処理理の並列列化を検討する

● ストレージの使い分けEBSやデータベース，S3などのストレージを使い分ける


Design for failure：全てのシステムが故障し得ることを前提とした設計例例えばAZ/DCが1つ潰れてもサービスが継続できるようにシステムを構成

AZ-a AZ-b

×

Service status : OK

Service status : stop Service status : OK

× ○ 2AZで同⼀一システムが稼働しており，⽚片系が潰れてもサービス継続可能

Design for Failure


Multi-AZ DB（RDS）配置：完全同期DBを複数AZに配置し，障害時は⾃自動切切替データを複数AZに同期保存し，障害発⽣生時に⾃自動フェイルオーバーすることによりRPOゼロを実現（RTO：3-5分） DB Snapshot：S3にDBのバックアップを取得し，万が⼀一のリカバリ等で利利⽤用

AZ間でデータを同期コピーする障害対策と共に万が⼀一に備えてスナップショットもS3に保存

Region

Multi-AZ

アベイラビリティゾーン

アベイラビリティゾーン

RDS対応エンジン • MySQL • Oracle • PostgreSQL • SQL Server（東京リージョンではMulti-AZ⾮非対応）

Design for Failure


サーバ冗⻑⾧長化：複数サーバをAZ内，複数AZに冗⻑⾧長化して設置し，ELBに紐紐付け ELBの利利⽤用：ELBはAWSが冗⻑⾧長化しており，利利⽤用すれば⾃自動で冗⻑⾧長化・疎結合化サーバが落落ちても他サーバで継続処理理し，可⽤用性担保と負荷分散を同時に実現

HTTP/HTTPS/TCPのみを通すような設定も可能（Firewall機能も兼用可）

EC2 Server

EC2 Server

ELB

EC2 Server

EC2 Server

Availability Zone #1

Availability Zone #2

フロント/バックエンドの接続にもELBを利利⽤用し，疎結合化してTier毎に冗⻑⾧長化

Web Server

Web Server

Web Server

AP Server

AP Server

AP Server

Web Server

Web Server

Web Server

AP Server

AP Server

AP Server

疎結合化

Design for Failure＋コンポーネントの疎結合化


Auto-Scaling：設定した負荷条件に応じてサーバ数を増減，⾃自動復復旧監視システムと連携し，サーバ負荷増加の場合は⾃自動でサーバを追加，減少の場合は⾃自動で削除する（サーバ上限/下限数，増加/削除単位，等を設定可能） ※起動するサーバを前もってイメージ化して⽤用意しておく（AMI）

フロントエンドとバックエンドのサーバそれぞれに利利⽤用し，Tier毎に可⽤用性を担保

AMIAutoScaling

Auto scaling Group

CloudWatchEC2

ServerEC2

ServerEC2

Server

③新サーバ追加&障害サーバ削除

①サーバ障害検知

②AutoScalingトリガ

Availability Zone #1 Availability Zone #2

④データや設定をロード

Design for Failure＋スケーラブルな構成


ネットワーク冗⻑⾧長化：AWS環境へのアクセス経路路も冗⻑⾧長化して保守・運⽤用 AWSのVPN GatewayはAWSが冗⻑⾧長化しており，企業側を冗⻑⾧長化して複数経路路化

内部ルータ故障や1経路路遮断時でも保守・運⽤用できる経路路を確保

Design for Failure


DynamoDBセッション管理理：セッション情報を別管理理しステートレスサーバ化⾼高性能なNoSQL DBであるDynamoDBに⼀一時的にセッション情報を保存し，⾼高負荷時であってもボトルネックを作らない構成を実現

セッション情報をDynamoDBに保存し，サーバ障害時は別サーバで情報取得して処理理を継続

ステートフルステートレス

EC2 Server

ELB

EC2 Server

EC2 Serverセッション情報A セッション情報B EC2

Server

ELB

EC2 Server

EC2 Server

セッション情報A

セッション情報B

サーバ障害が発⽣生するとセッション情報が喪失

コンポーネントの疎結合化


リソース量量制限がない点を活⽤用し，処理理を並列列化して効率率率化 RDSリードレプリカ：DBからの読み出しを並列列化して性能向上，負荷低減

書き込みはマスターDB，読み出しはリードレプリカとすることで書き込み性能も向上

RDS DB （マスター）

⾮非同期レプリケーション⾮非同期レプリケーション

EC2 Server

EC2 Server

RDS DB （Readレプリカ）

RDS DB （Readレプリカ）

Read Write Read

EC2 Server

EC2 Server

EC2 Server

EC2 Server

RDSリードレプリカ対応エンジン • MySQLのみ

並列列処理理の実装


要求される性能，条件等に応じてストレージを使い分けて運⽤用負荷を低減 S3静的ファイルホスティング：動的⽣生成が不不要なファイルをS3に置くことでファイルの可⽤用性を向上させると共に，EC2の負荷を軽減する

世界中に配信が必要な場合にはS3をオリジンとしてCDNであるCloudFrontも利利⽤用可能

AWS Cloud

S3EC2 EC2

RDS

Web App

Web App

DB

AZ1 AZ2

static.example.com

www.example.com

ELB

ストレージの使い分け


パブリッククラウドに対する３大懸念

セキュリティ

SLA

スイッチングリスク

19


ドコモの情報管理体制　（HPより）2005年4月の個人情報保護法の全面施行に伴い、個人情報保護法対策や情報漏えい等に対する全社的なマネジメントの実施、及び社内管理情報に関する方針策定、規程類の制改定等、一元的な情報管理の体制の整備・構築を行う部門として、情報セキュリティ部を設置し、個人情報取扱端末の管理、業務従事者に対する教育、業務委託先会社の監督、技術的セキュリティに関するチェックの強化等、セキュリティ管理の徹底に努めてまいりました。

20


情報セキュリティ部法務部

R＆Dビジネス部（新規事業）

情報システム部


私の誇りだったオンプレミスソリューション(2009-)

22


RedShiftを利用したデータ分析基盤

23

Data

o業務系システム（分析）での利用開始(2014) ØWeb系システム → 業務系システム → ミッションクリティカルシステム

ドコモデータセンター


当社情報セキュリティ部のセキュリティチェック項目

24

230


アカウント管理理：IAM，MFAを利利⽤用してユーザ・権限管理理を厳格化 MFAでマスターアカウント利利⽤用制限，各IAMユーザの権限を適切切に制限

アクセス元，および各ユーザがアクセスできるリソース，機能を制限し，重要操作はMFA利利⽤用限定

AWS account owner (master)

Developer (IAM) Operator (IAM)

Administrator (IAM)

Developer EC2: R/W RDS: R S3: R/W

Operator EC2: - RDS: - S3: R

Administrator EC2: R/W RDS: R/W S3: R/W

× ×△ △

EC2に対して権限を付与できるIAM Roleも活⽤用

全レイヤでのセキュリティ


セキュリティグループ：コンポーネントへのアクセスを制限するFirewall機能サーバ内部を変更更することなく，アクセス元/先を制限し不不正アクセスを排除

アクセス元，および各ユーザがアクセスできるリソース，機能を制限し，重要操作はMFA利利⽤用限定

全レイヤでのセキュリティ


VPCの発展(2009-）

27

セキュリティグループの拡張(in/outのフィルタリング）実行中のインスタンスのセキュリティグループの変更

ダイレクトインターネット接続サブネット間のトラフィックを制御できるNACL等々(2011-)


AWSのセキュリティ機能

28

IAM ROLEは一時的なトークンで、予め設定された権限を制御するサービス。

AWSリソースに対するアクション、アクセス権限を管理できるサービス。Identity Access Managementの略。

IAM ROLE

IAM

CLOUDTRAILCLOUDTRAILはAWS API の呼び出しを記録し、ログを残すことができるサービス。


AWS Summit Japan 2014 E-JAWSセッションにて・・・

29

羨ましいわ．そんなノウハウ，ドコモさん

だけに貯めとかんと外にも出しくれはったらええのに

（東急ハンズCIO 長谷川秀樹氏）


そうか！

30

＝当社の偉大なアセット

ユーザー企業によるユーザー企業のためのクラウドソリューション誕生の瞬間


ログ管理理Firewall/NACLアクセス制御

AWS自体が対策

AWS機能を利用して対策

ドコモ独自で対策

パターン化＆テンプレ化

共有責任モデル


構成プログラミング（テンプレート化）IAM ROLE

CloudTrail

IAMCLOUDWATCH


クラウドはプログラムできるデータセンター

33

シンプルなWebサーバ

しゃべってコンシェル（Cloud-native）

データ分析基盤（On premise-hybrid）


AWS Cloud Formation –環境構成をスクリプトに従ってデプロイする –利用料無料


お問い合わせ先

[email protected]

サービス紹介ページはこちら

https://www.39works.net/assets/dcm-cloudconsulting

ユーザー企業によるユザー企業のためのクラウドソリューション

mailto:[email protected]://www.39works.net/assets/dcm-cloudconsulting


効果

36

「ドコモ・クラウドパッケージ」 

を利用しなかった場合

「ドコモ・クラウドパッケージ」 

を利用した場合


ベジタリア+ウォーターセル + 新潟市 +d

37

M2M Server

データストレージ

水位・水温気温・湿度

ピンポイント天候予測、農作業記録、病害虫注意報など

地図情報・航空写真を利用した営農管理

多圃場の管理


ドコモのセキュリテイ（←詳しく言えませんが）をテンプレート一発で実現

38

情報管理規定

情報管理細則

故意による不正行為抑止

セキュリティ対策基準

サイバー攻撃対応

情報管理マニュアル

顧客情報管理マニュアル

内部・外部のログ定期的なログ調査の実施アラートシステム権限付与ルールアカウント管理入退室管理データ暗号化立ち入り監査

情報セキュリティ監査サイバー攻撃対応


15世紀 21世紀初頭


販売取次パートナーのご紹介

40

アイレット株式会社 Cloudpack事業部様

NTTデータ様


ドコモ・クラウドパッケージ Updates2015年5月までの新サービス、および各種新機能をキャッチアップした、 アップデート版DCPの提供開始【本日リリース】

コスト監視用ツール『Cost Visualizer』の提供開始【6月中旬】 （有償オプション）

ドコモのビッグデータ分析ノウハウを用いたコンサルティングの提供 【今夏頃提供開始】

41


私の夢

42

APIエコノミー：企業間連携によるイノベーションの実現

Bild: Mimi Potter / fotolia.dehttps://en.fotolia.com/id/59201779


ドコモのブランドビジョン

いつか、あたりまえになることを。

43

nttドコモの aws 開発ガイドラインと セキュリティデザインパ …€¦ ·...

Documents

nttドコモの aws 開発ガイドラインとセキュリティデザインパ …€¦ ·...