Salesforce1 PlatformアーキテクチャWebinar


Published on

5月23日に行われた「Salesforce1 PlatformアーキテクチャWebinar」のスライドです。

Published in: Technology

Salesforce1 PlatformアーキテクチャWebinar

  1. 1. #forcedotcomjp Salesforce1 PlatformアーキテクチャWebinar 株式会社セールスフォース・ドットコム
  2. 2. #forcedotcomjp Safe Harbor Safe harbor statement under the Private Securities Litigation Reform Act of 1995: This presentation may contain forward-looking statements that involve risks, uncertainties, and assumptions. If any such uncertainties materialize or if any of the assumptions proves incorrect, the results of, inc. could differ materially from the results expressed or implied by the forward-looking statements we make. All statements other than statements of historical fact could be deemed forward-looking, including any projections of product or service availability, subscriber growth, earnings, revenues, or other financial items and any statements regarding strategies or plans of management for future operations, statements of belief, any statements concerning new, planned, or upgraded services or technology developments and customer contracts or use of our services. The risks and uncertainties referred to above include – but are not limited to – risks associated with developing and delivering new functionality for our service, new products and services, our new business model, our past operating losses, possible fluctuations in our operating results and rate of growth, interruptions or delays in our Web hosting, breach of our security measures, the outcome of any litigation, risks associated with completed and any possible mergers and acquisitions, the immature market in which we operate, our relatively limited operating history, our ability to expand, retain, and motivate our employees and manage our growth, new releases of our service and successful customer deployment, our limited history reselling products, and utilization and selling to larger enterprise customers. Further information on potential factors that could affect the financial results of, inc. is included in our annual report on Form 10-K for the most recent fiscal year and in our quarterly report on Form 10-Q for the most recent fiscal quarter. These documents and others containing important disclosures are available on the SEC Filings section of the Investor Information section of our Web site. Any unreleased services or features referenced in this or other presentations, press releases or public statements are not currently available and may not be delivered on time or at all. Customers who purchase our services should make the purchase decisions based upon features that are currently available., inc. assumes no obligation and does not intend to update these forward-looking statements.
  3. 3. #forcedotcomjp#forcedotcomjp Speaker Kosuke Hayashida Lead Solution Engineer , Japan @hayakou
  4. 4. #forcedotcomjp Developer Forceをフォローください @developerforcej/ #forcedotcomjp Developer Force Japan +Developer Force Japan Developer Force Japan Developer Force Group
  5. 5. #forcedotcomjp Agenda §  Salesforce1 Platformの概要 §  Force.comアーキテクチャ §  Herokuアーキテクチャ §  Salesforce1 Platformの優位性 §  Salesforce1 Platformセキュリティ
  6. 6. Salesforce1 Platformの概要
  7. 7. #forcedotcomjp Salesforce1 Platform のアーキテクチャ Identity Salesforce1 Platform App Salesforce インフラストラクチャ Salesforce の共通データモデル API Heroku AWS Service Cloud Sales Cloud Chatter Salesforce1 mobile app Identity API Salesforce UI Communities 公開 Web アプリケーション ソーシャ ル ソーシャル バックエンドシステム 連携した AppExchange アプリケーション ERP あらゆるシステム 財務 カスタム アプリ ケーション ISV アプリ ケーション カスタム
 アプリ ケーション Heroku Connect
  8. 8. Social Enterprise Social Customer Engagement Salesforceのプラットフォーム・サービス エンドユーザ向けアプリケーション 開発プラットフォーム •  インスタント・デプロイメント •  即座にスケール可能 •  Facebook、Twitterとの統合 •  オープンな開発⾔言語・フレームワーク 社内アプリケーション向け開発 プラットフォーム •  ⾼高度度な抽象化 •  宣⾔言的な開発 •  ⾃自動化フレームワーク •  プロセス指向ツール・開発 •  ソーシャルデータモデル •  コラボレーション オープンAPI サードパーティアプリ アジリティ(俊敏性)
  9. 9. 最短のプロセスでアイデアをアプリケーションに変える アプリケー ション アイデア 従来のプラットフォーム 半年 ~ 1 年? ハードウェアの 購入、 セットアップ 複雑な ソフトウェアのイ ンストール ユーザ アクセスの 定義 レポート機能、分 析ツールの 設定 セキュリティの設 定、 テスト モバイル、 ソーシャルへ の対応 アプリケー ションの 開発 アプリケー ションの 開発 アプリケー ション アイデア 9
  10. 10. Force.comアーキテクチャ
  11. 11. Salesforceの構造 “Podアーキテクチャー” 顧客セットの マルチテナント スタック (インスタンス) データベース クラスターアプリケーションサーバー API サーバー 検索サーバー AP0 Pod ファイルサーバー(FileForce) u  “Pod” は、⼀一定規模の顧客セットを収容するように設計されたマルチテナントスタック(イ ンスタンス) u  新しいPodは、必要に応じて素早く簡単に⽤用意可能 u  個々のPodのキャパシティに対する最適なユーザ⽐比率率率を保つことによりパフォーマンスを維 持することが可能 u  ハードウェア: Dell と Sun サーバー, ⽇日⽴立立ストレージ, Cisco & F5ネットワークス u  ソフトウェア:クラスター化されたOracle データベース, Java アプリケーションサーバー
  12. 12. Salesforceの構造 “Podアーキテクチャー”による水平分散 §  ログイン時は共有リソースで提供されるログイン画面にアクセスし、ログイン後に自分が所属する組織のある、 適切なPodインスタンスに割り振られる。既存のPodインスタンスのリソースが逼迫した場合には、新たなPod を追加していく。 ネットワーク サービス ストレージ サービス バックアップ サービス モニタリング サービス NA0 Pod NA1 Pod NA2 Pod NA3 Pod NA4 Pod NA5 Pod EMEA Pod Japan Pod Sandbox Pod APAC Pod NA6 Pod NA7 Pod “N” Pod 共有リソース ログイン画面
  13. 13. Salesforceの構造  ディザスタリカバリー WAS Production Data Center Japan Production Data Center SJL Production Data Center CHI Production Data Center Production-Class Development Lab & Archive ASG Production Data Center Podインスタンスは地 域を跨ったグループで 管理しており、ミラー Podはその管理グルー プの中に作成される。 (日本の場合には、 ASGに作成) ほぼリアルタムでのデータレプリ ケーション 確立されたDRストラテジー セキュアに暗号化されたポイント toポイントでのデータレプリケー ション Weeklyスケージュールされた バックアップコピーMultiple 全体 コピー / Multiple 差分コピー キャリア依存の無いネットワーク 戦略 MPLS / VPLS バックボーンアー キテクチャー Focus on Infrastructure は100%ホットスタンバイの別リージョンにある、ミラーPodに ほぼリアルタイムでデータレプリケーションを実施している。セカンダリーPodは 100%プライマリーデータセンターと同等のキャパシティーを実装 (host, network, and storage)
  14. 14. Salesforceの構造 マルチテナントの仕組み §  Force.comではサービスを利用するユーザが共通化された1つのプラットフォームを利用するマルチテナント型アーキテクチャを 採用しており、ガバナンスの効いたセキュアな運用と各種開発資源と品質の集中管理を実現している。 汎 用 性 高 ー 基 盤 マルチテナント型 安定した運用 高品質なシス テム管理 少数精鋭体制による 集中化されたシステム 管理/運用 統一化された拡張可能 なプラットフォーム (1つの構成/コード) 最新のソフト ウェアの提供 成熟化 連携プラット フォームの提供 公開APIによるシステ ム間連携 新規アプリケーショ ン開発 安 心 運 用 環 境 開発プラット フォームの提供 ユーザごとの カスタマイズ が可能 Force.comではデータベースも全ユーザが共通のデータベースを利用するため、データを格納する領域 とユーザ固有の情報を分離して管理することにより、カスタマイズ性を持たせつつバージョンアップの影響 の少ないデータベース環境を実現している。(データベースの仮想化) + + SalesforceのCRMも Force.com上で構築
  15. 15. Salesforceの構造 下位互換性を実現するシングルコード §  Force.comのサーバでは最新の1つのバージョンが稼働しているが、ユーザが開発したアプリケーションの動 作を保証するために旧バージョンのAPIもエミュレートして実行する機能も含まれている。その為開発したプロ グラムのAPIが古かったとしても変更なく実行出来る仕組みを持っている。 プログラムA (API.18) 開発 プログラムA (API.18) Ver18で実行 明示的にAPIをバージョンアップしない限りはそのままのAPIバージョンで実行される。
  16. 16. Salesforceの構造 バージョンアップ耐性を支える抽象化 Java Force.comでは独自のプログラミング言語を拡張することにより、実行環境のフレームワークやアプリケーション サーバ、Javaなど下位のプラットフォームのバージョンアップが上位のアプリケーションに影響を及ばさない。 Java ミドルウェア (APサーバ,ワークフロー) アプリケーション フレームワーク 拡張モジュール (認証/認可,リソースアクセスなど) アプリケーション Java アプリケーションサーバー アプリケーション フレームワーク プログラミング言語拡張 (Apex) アプリケーション 拡張モジュール (認証/認可,各種リソースアクセス, ワークフローなど) JavaやAPサーバの バージョンアップ の影響を受けるライン Force.comでは独自の プログラミング言語を 提供する事で実行環境 の影響を分離している Platform Force.comではミドルウェアやOSの依存を受けないよう、Javaを拡張したPaaS向けの独自プログラミン グ言語(APEX)を提供している。
  17. 17. データ管理の仕組み メタデータによるデータ管理 Salesforceアプリケーション 各ユーザの パスワードは SHA-‐‑‒256   hash  with  salt で暗号化 抽出 •  利用者情報/オブジェクト情報/抽出条件によりレコードを抽出 結合 •  複数の参照レコードを結合 情報 生成 •  データ定義情報(メタデータ)よりデータから情報を生成 マルチテナントデータベース    ⇒  このレベルでは「データ」を管理理している状態 ‥500項⽬目 データ定義情報 (メタデータ) 全顧客の⼊入⼒力力データ を単⼀一のテーブルに 格納 (数⼗十億レコード) データベース管理理者 例例)  株式会社XYZのお客様情報に保存している⾦金金融さんの⼝口座番号 情報 Salesforce利利⽤用者 ログイン アクセス不不可 Org ID Object ID Record ID Field1 Field2 Field3 Field4 00D100000005qRW 01I100000008ymS 00110000005Xrjl 1235685 8320222 62500 12153351 00D100000018AsK 01I100000002tzz 00310000002yQgz 12345 120000256 20092526 00310000002yQh1 00D100000024Wte 01I100000004u04 00Q10000001w9gn 03456235 마케팅 사용자 12354961 50 00D100000022Tae 01I10000000TfZ9 00Q100000041LZO 東京 122586 0120330968 20050 00D100000012Ate 01I10000000TfZA 00Q100000041Lby 55697 01I10000000TfZA 00D100000019Qte Jim 00D100000015Qte 01I100000008tzv 00Q10000001w9ar 36987584 122586 01I100000008tzw 聯邦識別碼 00D100000033Bte 01I100000008tzw 00610000005jtOA 1258963 122586 ชื่อเล่นของกลุ่มผู 12254956 00D100000008fpj 01I100000008ubL 00610000005jtUO e1250ee 12235896 0925596332 12354468 システム利用組織 情報名 個人名 口座番号 株式会社XYZ お客様情報 金融 太郎 12345 Salesforceでは、データ、データの定義情報、アプリケーションコードの三つが揃って 初めて「データ」を「情報」として確認できます。
  18. 18. データ管理の仕組み(Custom Object) 全体テーブル構成 ※実データと属性情報を分けて管理する事で、組み合わせないと、情報として意味を持つデータとならない ユーザデータ管理領域 メタデータによるユーザデータ管理 n  Objectsテーブル Ø  各組織が任意のアプリケーション用に定義したカスタムオブジェクト (テーブルやエンティティ) に関する情報を格納 n  Fieldsテーブル Ø  任意の組織がカスタムオブジェクトに対して定義したカスタム項目(列や属性) に関する情報を格納 n  Dataテーブル Ø  Objects とFields 内のメタデータの定義に基づいて、すべてのカスタムオブジェクトと
  19. 19. データ管理の仕組み 大量データ利用時の機能 n  Skinny Table Ø  専用に、特定オブジェクトの必要な項目のみでコンパクトに構成されたテーブル。 Ø  利用するには、サポート経由での依頼が必要。 n  Division Ø  検索対象のテーブルを論理分割する機能。組織単位で有効かされ、全てのオブジェクトにDivisionフィールドが追加され、ユ ーザのプロファイルに紐づいたDivisionフィールドのレコードのみに対象を絞る事により、大量データのアクセスでのアクセ ス効率を上げる。 オブジェクトA 東京ユーザ オブジェクトA (東京) オブジェクトA (神奈川) ・・・・ 神奈川ユーザ Divisionフィールドに所属地域を利用 所属地域単位に論理分割 セールスフォースでの大量データのアクセスは、各オブジェクトに適切なインデックスキーを設定してもらい、アクセス を効率化することが基本となる。 しかし、全社展開などで利用人数が増えるケースでは、それだけではデータ量をさばけないようなケースもある。 その場合の為に、セールスフォースでは以下の機能を提供している。
  20. 20. データ管理の仕組み データベース管理 データベースクラスター アプリケーション サーバー API サーバー 検索 サーバー AP0 Pod 組織A 組織B 組織C 組織D 組織Aユーザ 組織Bユーザ 組織Cユーザ 組織Dユーザ データベースは、Podインスタンス単位に1データベースが存在し、マルチテナント型で提供している。しかし、契約組織ごとにデータ ベースは論理分割されており、契約している組織のデータ以外にはアクセスが出来ない。
  21. 21. 既存システムとのデータ連携 実現手段 プレゼンテーション層 データベース層 プロセス層 ・マッシュアップ ・Canvas API ・JavaScript連携(Ajax,JSONP) ・Web サービス(SOAP) ・サービス統合(ESB) ・アプリケーション統合(EAI) ・リソース連携  (REST/SOAP,DB処理,OData) ・一括データ連携(バルク処理,ETL) 外部システム セキュリティ
  22. 22. 既存システムとのデータ連携 連携インターフェース機能 その他、メタデータAPI(設定変更に利用)、Web-to-X、電子メール-to-X、CTI向けインターフェース、シング ルサインオン向けインターフェース等なども提供しています。 連携サーバー 外部システム 連携先システム ①Web Services API (SOAP/REST API) ②Bulk API (バルクAPI, ETL on ISV) ③Apex Web Services (Apex SOAP/REST API) ④AP/SP Integration (EAI/ESB on ISV) ⑤Outbound Message(アウトバウンドメッセージ) ⑥Canvas/マッシュアップ/Ajax Proxy(Ajax) 自社開発 や ミドルウェア データ連携 画面連携 Application Logic Data User Interface Webサービス プロセス連携 Salesforceとのシステム連携には、Webサービスを基本とした様々なインターフェースを提供しています。 データ連携では、各インターフェースはリアルタイムからバッチ連携まで場面に応じて柔軟に選択可能、また 画面連携ではマッシュアップにより既存システムを活かしながら簡易にかつ低コストで実現が可能です。その 他、ホームページ連携や電子メール連携などのインターフェースも提供しています。
  23. 23. Salesforceの外部との認証連携機能 ■代理認証によるSSO   ⇒外部の認証サーバーにSalesforceの認証処理を委任 ■SAML連携1によるSSO   ⇒SAMLにより外部システムと認証連携(双方向可能) ■認証プロバイダによるSSO   ⇒OpenID connectを利用した認証連携    (Google,amazon.comなど) ■リモート接続   ⇒OAuthを利用したAPI連携
  24. 24. 認証の仕組みとシングルサインオン SAML  ⇒  SSOを実現するための認証情報の表現⽅方法や、伝達⽅方法を定義したプロトコル アイデンティティ・プロバイダ(IdP)    ⇒認証を⾏行行い、認証情報をアサーションとしてSPへ発⾏行行する役割を担う サービスプロバイダ(SP)    ⇒シングルサインオン対象のシステム。IdPに認証を委任し、IdPによる認証情報を信頼して利利⽤用者にサービスを提供す る役割を担う アサーション  ⇒  IdPが本⼈人性を証明するために発⾏行行する⽂文書。属性やアクセス権情報などを含むこともある ⽤用語説明 独⾃自の認証 システムとの統合 外部認証 プロバイダ 利利⽤用 SSOの利利⽤用 ⼿手段:OpenID  connect 外部サービスプロバイダ(Salesforceの他組織、 Facebook©、Janrain©)のログイン情報を使⽤用 して、Salesforce  組織にユーザがログインでき るようにする ⼿手段:代理理認証 ログイン時に予めオンプレ内に構築した認証⽤用 Web  サービスへusername、password、およ び接続元IPアドレス  を  渡し、Webサービスの 結果に基づきログイン許可を与える ⼿手段:SAML連携 外部IdPに認証を委任し、IdPから発⾏行行されたア サーション(認証情報)をもとにユーザを識識別 します。 SAMLに対応していない認証システムでもSSOを 実現できる ソーシャルアカウントによるSalesforceログイ ンが可能となる SAMLに対応した統合認証システムであれば設定の みでSSOを実現できるため⼯工数が少なくて済む Salesforceには認証情報のみが渡される(パスワー ド情報は渡されない)ため代理理認証に⽐比べ安全。 利利⽤用ケース メリット WebサービスプロバイダへSalesforceからアウ トバウンド通信が必要となり、overVPN網を通 らず認証情報が流流通する オンプレミスのDMZ内にWebサービスプロバイ ダを構築する必要がある Salesforce、認証基盤両⽅方にパスワード情報が 流流通するためSAML⽅方式に⽐比べ安全性が低い 利利⽤用できる認証プロバイダがまだ限定的 SAMLに対応した認証システムが必要 デメリット ※  いずれの⽅方式も統合認証のための仕組みであり認可の統合については別の仕組みが必要となります 実現⼿手段と⽅方法 Salesforce には外部の認証情報をもとにサインオンする仕組みとして「代理認証」、「認証プロバイダ」、「SAML を使用する統合認証」の3方式があります。
  25. 25. Herokuアーキテクチャ
  26. 26. Herokuアーキテクチャ アプリケーションのログを集中管理するレイヤー アプリケーション実行環境のベース UbuntuベースのLinux コンテナ(LXC)の集合体 Amazon Web Service Platform リクエストの負荷分散 Ubuntu Linuxベースの Linuxシステム(コンテナ)
  27. 27. Heroku のアーキテクチャ Control SurfaceAPI Elastic Load Balancer (Routing Mesh) Dyno データベース アドオン
  28. 28. §  Dyno  はアプリケーションの実⾏行行プロセス §  ひとつひとつのDynoには独⽴立立して完全な実⾏行行環境が含まれる –  アプリケーション本体 –  メモリ –  設定(環境変数など) –  依存ライブラリ –  アプリケーション実⾏行行環境 (アプリケーション・コンテナなど) §  不不安定になったDynoは⾃自動的に再起動される §  柔軟な拡張・縮退が可能 Dynoとは?
  29. 29. §  24時間365⽇日のモニタリング §  1.0TBのストレージ容量量 §  PostgreSQL  9.3  (9.2,9.1,9.0もサポート) §  ⽇日時の⾃自動バックアップ §  データ・レプリケーション(Fork&Follow) §  データクリップ §  PostgreSQLクライアントの直接接続 拡張性・信頼性・セキュリティが保証されたPostgreSQLを標準で提供 herokupostgres
  30. 30. アドオンによる拡張 アドオンライブラリでアプリケーションに機能を追加することが可能 § 100以上のアドオンが提供 § シンプルなプロビジョニング § 統⼀一された課⾦金金⽅方法  
  31. 31. よく利利⽤用されるアドオン New Relic 監視 Redis To Go キーバリューストア Heroku Postgres RDB Websolr 全文検索エンジン Sendgrid メール配信 Memcache 分散メモリキャッシュ Exceptional エラー管理、通知 MongoHQ ドキュメント指向データベース ZerigoDNS アプリケーションのDNS管理 Airbrake 障害検知、管理 以下のカテゴリにAdd-‐‑‒onがリストされています データストア、検索索、ログ、EmailとSMS、ワーカーとキューイング、分析、 キャッシュ、モニタリング,  メディア,  ユーティリティ,  ⽀支払い
  32. 32. Herokuデモ
  33. 33. Salesforce1 Platformの優位性
  34. 34. Azure Web サイト クラウドプラットフォームの分布 §  各プラットフォームサービス(PaaS/IaaS)の位置づけ 開発生産性 運 用 効 率 構 成 自 由 度 複雑性 Private cloud 既存システムの移管がしやすい 即効性のある構築が出来る 既存の手法が流用しやすい 要件にマッチした環境の構築 維持管理のしやすさ Azure クラウド 生 産 性 向 上 ・生産性が高いほど利用目的が明確になるため、利用範囲が限定化される ・維持管理がしやすいほど利用ツールが特定化されるため自由度はなくなる Azure IaaS
  35. 35. プラットフォームのルールとそれにより得られる利益 SaaS [アプリケーションレベルの抽 象化] PaaS [アプリケーション実 行環境レベルの抽 象化] IaaS [基盤レベルの 抽象化] •  クラウドのサービスはプラットフォームとしてフレームワークが提供され、提供するサービスの レイヤーごとに得られる利益とそれに伴い従うべきルールが存在します。 得られる利益 従うルール ・光熱費(データセンター)の削減 ・物理コスト削減 (スペース・HWなどの費用) ・人件費の削減(HW担当者) ・データベースの構築コストの削減 ・サーバ構築コストの削減 ・アプリ実行環境の構築コストの削減 +IaaSの範囲 ・複雑なデータ設計の削減 ・プログラミングの削減 ・業務に必要な機能の削減  (認証・ワークフローなど) +PaaSまでの範囲 ・複雑な画面構築の制限  (コーディングを伴う) ・独自のデータ構造定義の制限 +PaaSまでのルール ・MW製品の限定(Web/AP,DBなど) ・プログラミング言語の限定 ・基盤リソースの制限 (ファイル、ディレクトリ) +IaaSのルール ・ロケーションの制限 (物理的な場所) ・独自のHWの導入の制限
  36. 36. ・ロケーション(場所) ・ネットワーク ・不正アクセス など ・ハードウェア・ミドルウェア ・開発(人・ソフトウェア) ・運用(人・ソフトウェア) など ・サービス展開 ・急なリソース不足への対応 ・要件変更 など Salesforceプラットフォームの優位性 §  Salesforceプラットフォームでは、ユーザ業務システムやコンシューマ向けサービスといった サービスを、それぞれに必要なセキュリティ要件も満たしたうえで、迅速かつ安価に実現す る。 Cost Speed Security システム立ち上げにおける重要な要素 ユーザー部門 ・SpeedとCostを重視 システム担当 ・CostとSecurityを重視
  37. 37. Salesforceプラットフォームの得意・不得意領域 得意領域 •  階層によるワークフローや、アクセス権を必要とした業務システム •  Excelで対応する、ダッシュボードやレポートが必要な領域 •  一定期間だけ必要とするようなサービス •  モバイル対応が必須な領域 不得意領域 •  大量のトランザクションデータを安全に保管する領域 •  閉域網を必要とする、データセンターの拡張(BCPなど) •  既存システムの単純な移管 •  大規模データを対象としたDWH
  38. 38. Salesforce1 Platformセキュリティ
  39. 39. アプリケーション •  全てのパスワードは暗号化されている •  高セキュアなセッションキー管理 •  マルチテナントデータアクセス管理 •  セキュリティ侵害に対する自己モニタリング機能 ファイヤーウォール •  コントロールされた境界ファ イヤーウォール •  IDS •  プロアクティブなログ監視 インターネット •  全ての通信における128-bit SSL •  Verisign 証明書 物理セキュリティ •  完全にセキュアなデータセンター •  24x7 オンサイトセキュリティスタッフ •  生体認証システム •  エスコートによる入室管理 企業ポリシー&ルール •  Salesforce,com の一般社 員は、お客様のデータに対す るアクセス権を一切持ちません ユーザー •  パスワードポリシー •  アクセス制御 •  認証ログ監査 •  柔軟なデータシェアリングモデル •  フィールドレベルセキュリティ ネットワーク/ホスト •  最小限のIP •  要塞化されたOS •  セキュアなサービス セキュリティ概要 認証 •  ISO 27001 •  SOC 1, 2 & 3 •  SysTrust A Multi-tier Security Model
  40. 40. Salesforce.com内部アクセスコントロール §  セキュリティ管理されたプライベートネットワーク –  2ファクター認証 RSA SecureID –  Sunセキュアグローバルデスクトップ •  Restrict cut/paste, public IM, data copying –  Bastionターミナルサービス –  Bluecoatプロキシーサーバー §  最小限の権限のみを設定 §  正社員のみによる管理・コントロール §  セキュリティ担当社員採用時での非常に厳密なバックグラウンド審査 –  採用するに相応しい者であるか –  過去7年における犯罪履歴チェック –  職歴、学位チェック –  ソーシャルセキュリティーナンバー、運転免許書 –  リファレンスチェック §  データベースアクティビティファイヤーウォール
  41. 41. Salesforceの情報セキュリティ対策 §  当社では、経済協力開発機構(OECD)のガイドによる情報セキュリティの3大基本理念(C.I.A)に基づき、大規模なセキュリティ 投資を実施し、さらに監査性の考え方を加えて、総合的な情報セキュリティ対策を実施しております。  Confidentiality 機密性 Integrity 保全性 Availability 可用性 情報セキュリティにおけるC.I.A 大規模なセキュリティ投資 Auditability 監査性 機密性(Confidentiality) - 情報が許可された者だけがアクセスできること •  大規模投資による世界最高水準のセキュアシステム •  限定された管理者による集中管理 •  職務分掌と相互検証体制 •  お客様のみが情報にアクセス可能 •  サードパーティによる脆弱性チェック •  グローバルオフイスでISO27001を取得 保全性(Integrity) - 情報が完全な状態であること •  センター内データスナップショット •  世界規模のデータセンター間リアルタイムレプリケーション •  日次テープバックアップ •  お客様サイトへのバックアップオプション 可用性(Availability) - 情報が必要な時にいつでもアクセスできること •  冗長化(N+1)システム •  ガスタービン発電による電力バックアップ •  99.9%以上の稼働率実績 •  平均250ms以下のページ処理時間 監査性(Auditability) – 透明性があること •  Trustサイトで稼働状況を公開 •  総務省「ASP ・ SaaS安全 ・ 信頼性に係る情報開示認定」に基づく情報開示 •  SSAE16 Soc1監査レポートを年二回提供可能
  42. 42. Herokuのセキュリティ —  Herokuプラットフォームはシステム・データ・運用における高いセキュリティを担保し、 —  安全なアプリケーション運用環境を提供しています。 システム セキュリティ データ セキュリティ 運用 セキュリティ 身元のしっかりした安心の運用者 厳格なプライバシーポリシー 万全のセキュリティ体制 第三者組織による脆弱性チェック Firewallによるアクセス制限 DDos攻撃の軽減 独立したアプリケーション実行環境 分離されたデータアクセス制御 冗長性を活用したディザスタリカバリ リソースの安全なバックアップ
  43. 43. データセンターのセキュリティ —  HerokuはAmazon Web Service(AWS)のデータセンターで稼働するプラットフォームです。 —  AWSのデータセンターは複数の外部認証を受けるだけでなくセキュアな運用が行われていて、Salesforceと 同様に強固なセキュリティを持っています。 ○認証 •  ISO 27001 •  SOC 1 and SOC 2/SSAE 16/ISAE 3402 (Previously SAS 70 Type II) •  PCI DSS Level 1 •  FISMA Moderate •  Sarbanes-Oxley (SOX) ○物理セキュリティ •  データセンターは目立たないビル("Amazon"と分からないビル)に収容し、ビルへのアクセスは厳しく制限している。 •  境界と入り口にはプロのガードマンとビデオ監視システムを備えている。 •  最新式の侵入者検知システムと様々な電子装置が使用されている。 •  入室を許可されているスタッフは二要素認証を最低2回パスしないとデータセンターのフロアに到達できない。 •  訪問者や外部の作業員は身分証明書の提示の後にサインをして入室し、内部では常にスタッフが横に付き添う。 •  従業員が辞めた場合、AWSに関連する部署を離れた場合には直ちにアクセス権が無効にされる。 •  顧客のデータにアクセスする可能性のある社員については、法律を遵守しつつも、より詳細な身上調査を実施する。 —  ※Amazon Web Services: Overview of Security Processesから抜粋
  44. 44. #forcedotcomjp Developer Forceをフォローください @developerforcej/ #forcedotcomjp Developer Force Japan +Developer Force Japan Developer Force Japan Developer Force Group