【ことはじめ】今さら聞けない!? ゼロトラストのきほん (Oracle Cloudウェビナーシリーズ: 2021年2月9日)

Oracle Cloud ウェビナー
エントリーシリーズ
【ことはじめ】今さら聞けない!? ゼロトラストのきほん
2021年2月9日
日本オラクル株式会社
テクノロジー事業戦略統括
大澤清吾, CISSP

Safe harbor statement
以下の事項は、弊社の一般的な製品の方向性に関する概要を説明するものです。また、
情報提供を唯一の目的とするものであり、いかなる契約にも組み込むことはできません。以
下の事項は、マテリアルやコード、機能を提供することを確約するものではないため、購買
決定を行う際の判断材料になさらないで下さい。
オラクル製品に関して記載されている機能の開発、リリース、時期及び価格については、弊
社の裁量により決定され、変更される可能性があります。

日本の官民の情報セキュリティに対する考え方は、2ステップ遅れているのが現状
情報セキュリティに対する考え方の進化：
ステップ 1
専守防衛: 境界防御
ステップ 2
守りのDX: データ中心の縦深防御
ステップ 3
攻めのDX: 攻めの情報セキュリティ
主たる目的
主要施策（例）
• ネットワーク層でのアクセス管理
• 物理的な入退館管理
• セキュリティ・バイ・デザイン
• セキュリティ運用の自動化
• 管理者といえども、全データへのアク
セスができないような仕組みの具備
• データを行・列単位でアクセス管理
• 個人情報保護を担保した上での、
情報連携・共有の推進
• データが複製・連携された際の、
セル単位でのアクセス管理
価値を生み出せる資産
となるデータを堅牢に守る
データを守りつつ、部署・他社間で
情報連携し企業価値を向上する
不審者、攻撃者が自社内に
入り込まないよう、境界を防御
Copyright © 2021, Oracle and/or its affiliates
3
多くの日本企業が考える情報セキュリティ
▼
欧米先進企業が考える情報セキュリティ
▼

ステップ１とステップ2,3 の違い
情報セキュリティに対する考え方の進化：
4
ステップ 1
専守防衛：境界防御
ステップ 2
守りのDX：データ中心の縦深防御
ステップ 3
攻めのDX：攻めの情報セキュリティ
守りの
セキュリティ
攻めの
セキュリティ

情報セキュリティにおける脅威は、外部脅威と内部脅威の2つに分類することが出来ます。標的型攻撃は起点となる
外部脅威の対策だけではなく、内部脅威に対するセキュリティ対策も重要となります。
情報セキュリティにおける脅威
5
外
部
脅
威
無差別型攻撃
✓ 成功事例の多いシステムの脆弱性を利用し、無差
別に行う
✓ システムの脆弱性（パッチの未適応）を狙う
◼ “85% ”のセキュリティ侵害は、CVEの発表後に発生(*1)
◼ クラウドサーバーをネット接続から“約52秒後”にサイバー攻撃の標的(*2)
◼ Amazon S3バケットの設定ミスを悪用し、無差別にクレジット
カード情報を窃取するスクリプトがばら撒かれる(*3)
標的型攻撃
✓ 組織の脆弱性を推定して、環境に応じて攻撃を行い、
成功するまで標的を繰り返し攻撃する
◼ Webアプリケーションの脆弱性をついた攻撃により内部に侵入(*4), インスタンスの資格情
報を盗み、ストレージから“暗号化されていないDBバックアップファイル”を奪取
◼ 被害者のネットワークへのアクセスを取得し、偵察活動を行う、データを盗み出すための
ネットワークリソース、バックアップ、またはその他の機密ファイルを探し出し、 “攻撃者は人
手によりランサムウェアを展開し、被害者のデータを暗号化“する (*5)
内
部
脅
威
従業員による不正アクセス
✓ 内部で権限を持つアカウントから重要な情報にアクセ
スし、外部に持ち出す
◼ 従業員が“顧客サポート用のデータベースへ不正アクセス” (*6)し、顧客情報を不正に
持ち出し、第三者へ売却
◼ SNSから技術開発担当へ接触し営業秘密情報持ち出し、中国企業に情報を提供
(*7)
◼ ライバル企業に転職した技術者が、転職前の企業の営業秘密情報を不正に取得(*8)
*1 : CISA: Top 30 Targeted High Risk Vulnerabilities *2 : https://japan.zdnet.com/article/35135993/ *3 : https://gigazine.net/news/20190712-magecart-hack-amazon-s3-buckets/
*4 : https://searchsecurity.techtarget.com/news/252467901/Capital-One-hack-highlights-SSRF-concerns-for-AWS *5 : https://www.ipa.go.jp/files/000084974.pdf
*6 : https://blog.trendmicro.com/trend-micro-discloses-insider-threat-impacting-some-of-its-consumer-customers/ *7 : https://www.nikkei.com/article/DGXMZO64989980U0A011C2AC8Z00
*8 : https://www.nikkei.com/article/DGXZQODG1204J0S1A110C2000000
内
部
脅
威
対
策
が
必
要

ゼロトラストセキュリティ
6

米国でのゼロトラストへの道程
7 Copyright © 2021, Oracle and/or its affiliates
データ量
1990 2000 2010 2020 …………
境界防御
（Perimeter Defense）
縦深防御
（Defense in Depth）
サイバーレジリエンス
（Cyber Resilience ）
ゼロトラスト又はデータドリブン防御
（Zero Trust or
Data-Driven Defense ）
Build Security Into Your
Network’s DNA: The Zero
Trust Network Architecture
Forrester 2010
Policy Decision Point(PDP)
Policy Enforcement Point(PEP)
X.500
電子ディレクトリ・サービス
情報機関改革及び
テロ予防法（2004）
Federal Identity, Credentialing
and Access Management (FICAM)
De-Perimeterization (非境界化)
- Jericho Forum 2007
DoDブラックコア
The Road to Zero Trust(Security):
DIB Zero Trust White Paper,
Defense Innovation Board 2019
DoD Digital Modernization Strategy,
Jun 2019
NIST SP 800-207
Zero Trust Architecture, 2020
エドワードスノーデン (2013)
アメリカ同時多発テロ事件 (2001)

2010年にForrester Research社により提唱。
全ての情報資産へのアクセスは信頼できないことを前提としたう
えで、ぞれぞれのアクセスに対してチェックし、信頼できるアクセス
のみ許可するモデルです。
2020年8月に米国国立標準技術研究所（NIST）から
「 Special Publication （ SP ） 800-207: Zero Trust
Architecture」が公開。全7章で構成されており、第2章
「Zero Trust Basics 」にて基本的な概念が記載されています。
ゼロトラスト・セキュリティとは？
NIST Special Publication 800-207
Zero Trust Architecture
Scott Rose
Oliver Borchert
Stu Mitchell
Sean Connelly
This publication is available free of charge from:
https://doi.org/10.6028/NIST.SP.800-207
C O M P U T E R S E C U R I T Y
NIST SP 800-207 ZERO TRUST ARCHITECTURE
v
This
publication
is
available
free
of
charge
from:
Table of Contents
1 Introduction ............................................................................................................ 1
1.1 History of Zero Trust Efforts Related to Federal Agencies.............................. 2
1.2 Structure of This Document ............................................................................ 2
2 Zero Trust Basics................................................................................................... 4
2.1 Tenets of Zero Trust ....................................................................................... 6
2.2 A Zero Trust View of a Network ...................................................................... 8
3 Logical Components of Zero Trust Architecture................................................. 9
3.1 Variations of Zero Trust Architecture Approaches ........................................ 11
3.1.1 ZTA Using Enhanced Identity Governance ........................................ 11
3.1.2 ZTA Using Micro-Segmentation ......................................................... 12
3.1.3 ZTA Using Network Infrastructure and Software Defined Perimeters. 12
3.2 Deployed Variations of the Abstract Architecture.......................................... 13
3.2.1 Device Agent/Gateway-Based Deployment........................................ 13
3.2.2 Enclave-Based Deployment ............................................................... 14
3.2.3 Resource Portal-Based Deployment .................................................. 15
3.2.4 Device Application Sandboxing .......................................................... 16
3.3 Trust Algorithm.............................................................................................. 17
3.3.1 Trust Algorithm Variations .................................................................. 19
3.4 Network/Environment Components .............................................................. 21
3.4.1 Network Requirements to Support ZTA.............................................. 21
4 Deployment Scenarios/Use Cases ..................................................................... 23
4.1 Enterprise with Satellite Facilities.................................................................. 23
4.2 Multi-cloud/Cloud-to-Cloud Enterprise .......................................................... 24
4.3 Enterprise with Contracted Services and/or Nonemployee Access .............. 25
4.4 Collaboration Across Enterprise Boundaries ................................................ 26
4.5 Enterprise with Public- or Customer-Facing Services................................... 27
5 Threats Associated with Zero Trust Architecture ............................................. 28
5.1 Subversion of ZTA Decision Process............................................................ 28
5.2 Denial-of-Service or Network Disruption....................................................... 28
5.3 Stolen Credentials/Insider Threat ................................................................. 29
5.4 Visibility on the Network................................................................................ 29
NIST SP 800-207 ZERO TRUST ARCHITECTURE
vi
This
publication
is
available
free
of
charge
from:
5.5 Storage of System and Network Information ................................................ 30
5.6 Reliance on Proprietary Data Formats or Solutions...................................... 30
5.7 Use of Non-person Entities (NPE) in ZTA Administration ............................. 30
6 Zero Trust Architecture and Possible Interactions with Existing Federal
Guidance...................................................................................................................... 32
6.1 ZTA and NIST Risk Management Framework .............................................. 32
6.2 Zero Trust and NIST Privacy Framework...................................................... 32
6.3 ZTA and Federal Identity, Credential, and Access Management Architecture
33
6.4 ZTA and Trusted Internet Connections 3.0................................................... 33
6.5 ZTA and EINSTEIN (NCPS – National Cybersecurity Protection System) ... 34
6.6 ZTA and DHS Continuous Diagnostics and Mitigations (CDM) Program...... 34
6.7 ZTA, Cloud Smart, and the Federal Data Strategy ....................................... 35
7 Migrating to a Zero Trust Architecture............................................................... 36
7.1 Pure Zero Trust Architecture......................................................................... 36
7.2 Hybrid ZTA and Perimeter-Based Architecture............................................. 36
7.3 Steps to Introducing ZTA to a Perimeter-Based Architected Network........... 37
7.3.1 Identify Actors on the Enterprise ........................................................ 38
7.3.2 Identify Assets Owned by the Enterprise............................................ 38
7.3.3 Identify Key Processes and Evaluate Risks Associated with Executing
Process ......................................................................................................... 39
7.3.4 Formulating Policies for the ZTA Candidate....................................... 39
7.3.5 Identifying Candidate Solutions .......................................................... 40
7.3.6 Initial Deployment and Monitoring ...................................................... 40
7.3.7 Expanding the ZTA............................................................................. 41
References................................................................................................................... 42
List of Appendices
Appendix A— Acronyms ............................................................................................ 45
Appendix B— Identified Gaps in the Current State-of-the-Art in ZTA .................... 46
B.1 Technology Survey ....................................................................................... 46
B.2 Gaps that Prevent an Immediate Move to ZTA............................................. 47
B.2.1 Lack of Common Terms for ZTA Design, Planning, and Procurement47
B.2.2 Perception that ZTA Conflicts with Existing Federal Cybersecurity
引用： https://csrc.nist.gov/publications/detail/sp/800-207/final

Special Publication（SP）800-207: Zero Trust Architectureの日本語版につきましては、
PwCコンサルティング合同会社がNISTから翻訳の許可を取得し、日本語訳を公開しております。
Special Publication（SP）800-207: Zero Trust Architecture（日本語版）
引用： https://www.pwc.com/jp/ja/knowledge/column/awareness-cyber-security/zero-trust-architecture-jp.html
NIST Special Publication 800-207
Scott Rose
Oliver Borchert
Stu Mitchell
Sean Connelly
C O M P U T E R S E C U R I T Y
PwC

第2章の基本的な概念では、情報リソースに対してアクセスが行われる際、ポリシー決定ポイント（PDP）/ ポリシー実施
ポイント（PEP）を介してチェックが行われ、アクセスの信頼性と妥当性を確認するモデルが提示されています。
例えば、アクセスを必要とする者にリソースを制限し、業務遂行に必要な最低限の権限（読み取り、書き込み、削除、
等）のみを付与することにある。これは、ゼロトラストが認証と認可という二つの基本的な領域に適用されることを意味し
ています。
800-207 Zero Trust Architecture
引用： NIST SP800-207 「ゼロトラスト・アーキテクチャ」の解説と日本語訳

ホテル（非接触型カード）で考える
ゼロトラストセキュリティ対策に必要なステップ
暗号化
鍵をかける
経路の制限
ホテルに入る経路を制限
認証
ホテルや部屋に入る際
にカードで本人確認多要素認証
追加で顔認証を実施
IDライフサイクル管理
宿泊日に過ぎたら
カードを失効させる最小権限
セーフティボックス
1
2
3
4
5
6
ホテルの玄関の鍵と個人の部屋の鍵の２か所
一般客、宿泊者、従業員毎にわける
ホテル内に一般客は入れない
利用者の部屋に間違えないかを確認
カードとは別の要素(生体情報)でセキュリティ担保
不正利用されないように、登録情報と連携させて
カードのアクセス権を制御
ホテルの人でも中を見ることができないように
管理者権限へのアクセス制御を実施
7
監査
カメラで監視
万が一犯罪が起きた場合に記録を確認

ITの対策
ゼロトラストセキュリティ対策に必要なステップ
暗号化
格納データと通信を暗号
経路の制限
アクセスする経路を制限
認証
シングルサインオン
多要素認証
厳格な本人確認
IDライフサイクル管理
人事イベントと連携した
ID・権限管理最小権限
認可(アクセス権の検証)
1
2
3
4
5
6
本番、バックアップも含めた保存状態 (Data at Rest)
転送状態(Data in Transit)暗号化
物理セキュリティ、NWセキュリティなどで重要なデータへ
アクセスできるルートを制御する
各サービスへの認証連携機能を利用し、本人確認の一元化
「知識情報」、「所持情報」、「生体情報」のうち、
2つ以上を組み合わせて認証
人事イベントと連携したID・権限の作成・変更・削除
業務に必要となるデータのみを表示し、
最小限の情報にとどめる
7
監査
監査証跡の記録
システムに対する攻撃への検知と証跡管理

競争上の優位性を得るためにデジタル環境を推進
デジタル近代化の目標
• 競争優位のために革新
• 効率化と能力向上のための最適化
• アジャイルかつ回復力のある防衛態勢のためにサイ
バーセキュリティを進化
• デジタルワークフォースのための人材育成
ゼロトラストセキュリティについて
「クラウドの導入」は、ゼロトラストの概念を実装するための
優れた候補となる。クラウド・インフラ自体が危殆化した場
合でも、ゼロ・トラストに準拠したアーキテクチャは、仮想
ネットワークに侵入しようとする敵対者からの保護を提
供。
その他に、「セキュリティの自動化とオーケストレーション」、
「暗号化の近代化」「分析」のポイントも紹介
アメリカ合衆国国防総省(DoD): デジタル近代化戦略
13
出典：DoD Digital Modernization Strategy Jun 2019

アメリカ合衆国国防総省(DoD) ：ゼロトラストセキュリティを提供
14
出典：https://www.afcea.org/content/dod-offer-zero-trust-architecture-year
ネットワーク中心のセキュリティモデルからデータ中心の
セキュリティモデルへのこのパラダイムシフトは、
最初にデータと重要なリソースを保護する方法に重点を置き、
次にネットワークに重点を置く
すべてを許可して例外で拒否するのではなく、すべての
[ネットワークアクセス]を拒否して例外で許可するという
基本的な前提を変更
巧妙な攻撃者は私たちの資格情報を盗み、特権に昇格し、
データを盗み出します。だからこそ、データ侵害を防ぐために、
ゼロトラストを採用する

1．ユーザーの検証
[認証＃1]
2．デバイスの検証
[認証＃2]
3．アクセス権の検証
[認可]
ゼロトラストへの道：データを守るための対策
IDアクセス管理
(利用の都度)
ネットワーク及び
デバイスの管理
必要最小限の権限付与
（毎回実施）
出典：Kurt DelBene, Milo Medin, Richard Murray, The Road to Zero Trust(Security): DIB Zero Trust White Paper, Defense Innovation Board, 9JUL2019, p.4.
PE/NPE
ユーザ／プログラム
ロール、属性及び
ポリシー等の整理
情報システム,物理システム
モバイル端末

ネットワークの境界が信頼できない世界でのセキュリティ担保
ゼロトラストへの道：実装におけるポイント
通信と格納データを100%
安全に暗号化し、堅牢で
安全な暗号化鍵管理を行
う
1 3 5
利用者が利用できるサービ
スとサーバーに対して、
100%の多要素認証
すべてのエンドユーザーの
デバイスを継続的にスキャン
共有アカウントの過剰な使
用の制限、特権ユーザー
管理の常備が必要
2
組織におけるユーザーの
役割に応じて厳密に
アクセス権を適用する
4
最終的に最も安全なのは、
インターネットに直接接続し
十分な回復力を持つ事
6
出典：Kurt DelBene, Milo Medin, Richard Murray, The Road to Zero Trust(Security): DIB Zero Trust White Paper, Defense Innovation Board, 9JUL2019, p.4.
16

今後求められるセキュリティ対策と日本の取り組むべき点
考慮点ゼロトラストセキュリティの考え方セキュリティ対策例日本企業の状況
ネットワーク
• 通信を監視し、未許可のクラウドサービスの
利用を制限
• CASB
• Cloud Proxy
• WAF
グローバルより
注力している
デバイス
• デバイスの認証を常に実施
• 全てのデバイスの保護を徹底
• EDR、EPP
• MDM グローバルと同様
IDアクセス管理
• ID・ユーザを必ず検証
• 必要に応じて多要素認証(MFA)を実施
• IAM
• PAM
• MFA
グローバルとより
対応が遅れている
アプリケーション • すべてのアクセスを制限し、不正操作を監視
• CASB、UEBA
• 標的型メール対策
• SIEM、SOAR
グローバルと同様
データ
• データが漏洩・改ざんされないように保護
• 必要最小限の権限付与
• 暗号化
• アクセス制御
グローバルとより
対応が遅れている
17 出典: Oracle and KPMG Threat Report 2020
安全なクラウドセキュリティ環境を整備するためには、ネットワークセキュリティだけでなく、
ゼロ・トラスト・セキュリティな対策が必要となります。

ID・アクセス管理(IAM)で日本企業が苦労している点発見された設定ミス：
グローバルと差が大きい TOP3
IDアクセス管理・データセキュリティの対応状況について：調査結果
18
1位
2位
セキュリティグループの誤設定
3位
機密情報が暗号化されていない
過剰な権限付与
37% 45%
33% 40%
25% 32%
IDアクセス管理・データセキュリティ対策に関して、日本企業は認証に加えて利用者に必要となる
最小権限の実現と誤設定の早期検知、暗号化に課題があり、改善が必要となっています。
アクセス
制御
暗号化
出典: Oracle and KPMG Threat Report 2020
① 人事イベントとの連携
② クラウドサービスへのIAMによる制御
③ アプリケーション/モバイル利用の制御
④ 権限管理
⑤ 多要素認証
太字：グローバルとの差が多いもの

クラウド時代に求められるIDアクセス管理基盤
19
自宅または
外出先
クラウド型ID・アクセス制御サービス
犯罪者
どのようにどこで
誰が
オンプレミス
アプリケーション
社内からは
ID/Passのみ
会社
クラウドサービス
多要素認証
リスクベース認証
シングル
サインオン
IDライフサイクル
管理
クラウド型のIDアクセス管理基盤により、ハイブリッドクラウドのIDライフサイクル管理の実現に加え、
利用者の特定や多要素認証によるセキュリティ強化、VPNの負荷軽減を実現します。
社外からは
二要素認証を要求
不審なログインは拒否
ID・アクセス管理

「データセキュリティ」の考え方
～米国での取り組みと考え方
• 米国国防のセキュリティ基準を制定しているNSA(National Security Agency)では、
2003年にNet-Centric Data Strategyという文書の中でデータの状態を3つに分類
• Data at Rest(保存状態)
• Data in Transit(転送状態)
• Data in Use(利用状態)
• Data at RestとData in Transitの状態での「暗号化」を指示。
=> 認可で権限を持っていることを確認し、暗号鍵を使って暗号化されたデータを参照
• Data in Use(利用状態)については、「最小権限（Least Privilege）」と
「Need to know」の原則との考えに乗っ取った対策を指示
=> 利用者が業務に必要となるデータのみを表示し、最小限の情報にとどめる
例) 「データベース管理者に対してもデータを見せない」、
「一般利用者には役割に応じた必要な情報のみを提供する」
20
アクセス権限には、暗号化とアクセス制御の両方が含まれる
データセキュリティ

オラクルのセキュリティへの
取り組み
21

出典：Oracle and KPMG Cloud Threat Report 2020
22

共有責任モデル
アプリがアクセスするデータ
Middleware
データベース
OS
Virtual Machine
サーバー・ストレージ
ネットワーク
物理
Middleware
データベース
OS
Virtual Machine
ネットワーク
物理
Middleware
データベース
OS
Virtual Machine
ネットワーク
物理
IaaS
PaaS
SaaS
ユーザー管理
クラウド
事業者管理
共有責任
23

共有責任モデル
Middleware
データベース
OS
Virtual Machine
ネットワーク
物理
Middleware
データベース
OS
Virtual Machine
ネットワーク
物理
Middleware
データベース
OS
Virtual Machine
ネットワーク
物理
IaaS
PaaS
SaaS
ユーザー管理
クラウド
事業者管理
共有責任
お客様側でツールの活用や
セキュリティ構成の管理を実施
SECURITY ON
THE CLOUD
SECURITY OF
THE CLOUD
オラクルはセキュアなクラウド・インフラ
とサービスを提供
24
Oracle が力を入れて
取り組んでいるところ

オラクルが実現する堅牢なセキュリティ
データ中心の
セキュリティ
自動化された
セキュリティ
管理
セキュリティ
・バイ・デザイン
SECURITY ON THE CLOUD
SECURITY OF THE CLOUD
＋
強力、完全なテナント分離
強制的な暗号化
(DB/Storage/Network)
階層型権限管理
特権ユーザーのアクセス制御
多要素認証とリスクベース認証
ボット対策とWAF(*)
脆弱性自動修復
セキュリティポリシーの自動有効
リスクのある設定を自動検知
自動化されたログ分析
25
Defense
In
Depth
重要情報の隠蔽セキュリティ構成
機密データ発見アクティビティ監査
DBセキュリティ対策の自動化
* WAF: Web Application Firewall

クラウドプラットフォームレベルでの環境隔離と暗号化
26
階層型権限管理
✓ 部署ごとの権限設定を実現
✓ コンパートメント間のリソースアクセスが可能な
為、部署を跨いだシステム構築も容易
✓ コンパートメントのQuota設定により使い過
ぎを抑止
強制的な暗号化
✓ OCIに存在するすべてのデータ・サービスは
Oracleがフルマネージドで暗号化
✓ データベースファイル,ストレージ
Block Volume, Boot Volume
✓ すべてのネットワーク通信も暗号化
強力、完全なテナント分離
✓ 分離された仮想ネットワークにより
情報漏洩のリスクを最小化
AD2
リージョン1
AD2
リージョン2
すべてのデータ
を暗号化
MACSec
高速・スケーラブルな
Layer2 暗号化
部署ごとにCompartment（サブアカウント）を作成
「コンパートメント」モデル
テナント
コンパートメント A コンパートメントB
ユーザーグループポリシー
ポリシーポリシー
部署-A 部署-B
セキュリティ
・バイ・デザイン
Hypervisor
VM VM VM
VM VM VM
ホストOS / カーネル
ネットワーク仮想化
物理サーバー

自動化されたEnd-to-Endのセキュリティで人的ミスを排除
27
パブリックアクセス不可
Oracle Cloud Guard Oracle Maximum Security Zone 自動パッチ適用
アップグレード
Autonomous
Database
• セキュリティ構成の評価
• ユーザーのリスク評価
• アクティビティの監査
• 機密データの発見
• データ・マスキング
自動化された
セキュリティ管理
Oracle Data Safe
リスクのある設定を自動検知
✓ 構成とアクティビティを監視
✓ 問題の特定、脅威を検出
✓ 問題の是正、顧客通知
セキュリティポリシーの自動有効
✓ ベスト・プラクティスを強制的に適用
✓ 初期段階からリソースのセキュリティを
確保
脆弱性の自動修復
✓ Autonomous Databaseによる
脆弱性自動修復
✓ Oracle Data Safeにより短時間で
セキュリティ・リスクを軽減

多層防御によるデータ中心のセキュリティ
外部からの攻撃
» ボットによる攻撃
» 標的型攻撃
» ランサムウェア
» DDoS
内部からの攻撃
» バックドア
» 内部不正
» 不正アクセス
特権ユーザー管理
ネットワーク
IDアクセス
管理
インフラ
ストラクチャ
データベース
Web
Application
Firewall
Identity
Cloud Service
Cloud Guard/
Maximum
Security Zone
Data Safe
強力、完全なテナント分離 / 階層型権限管理 / 強制的な暗号化
28
データ
Observability and Management / Management Cloud
強制的な
暗号化
Autonomous Linux Autonomous Database
データ中心の
セキュリティ
監査証跡

ゼロトラスト・セキュリティに基づいた設計
29
非常に安全な場所
Oracle Cloud Infrastructureは、接続・認証・利用は否認が前提（Default Deny）
• 許可を与えなければ何もできない：Security list、コンパートメント、ポリシーの設定等
Oracle Maximum Security Zone
Oracle Database Vault
セキュアな場所を継続的に監視
Oracle Cloud Guard
Oracle Data Safe

• 設定や運用上の問題によって発生するセキュリティ
リスクを自動検知し、インフラの安定的な運用に寄与
• 他社のクラウドサービスと比べて監視できる項目が広
く、 UI含め使い勝手が優れているため、効率的な運
用が可能
• 「Oracle Cloud Infrastructure」は、クラウドプラッ
トフォームレベルで環境隔離と強制的な暗号化がされ
ており、「Oracle Cloud Guard」と組みあわせること
で、お客様に安心して利用頂けるサービスを提供
ワークスアプリケーションズ様
30
ERPマネージド・サービスHUE Classic Cloud
で「Oracle Cloud Guard」を活用し、
セキュリティリスクを軽減

Oracle Cloud Infrastructure
セキュリティのプロもSaaS基盤としてOCIを選択
31
世界最大のコンピュータ
ネットワーク機器ベンダー
ハードウェアやソフトウェアセンサーから
テレメトリー情報を収集し、データを高度な
機械学習技術によって分析するSaaS
(Cisco Tetration) でOCIを採用
数千コア以上の大規模アプリケーションを
2ヶ月で稼働
インテリジェンス主導型の
セキュリティ企業
なりすまし攻撃、フィッシング、スパムによる
Eメール脅威の対策を提供するSaaSで
OCIを採用
高度なリアルタイム分析をベアメタル・
インスタンスを活用することでクラウドで実現
業界をリードする
サイバーセキュリティ企業
脅威の識別、調査、解決を行うクラウドベースの
SIEMソリューション(McAfee ESM Cloud)で
OCIを採用
他社クラウドに比べ1/4のコストで実現
60万データソースにおける1秒当たり
50万イベントをサポート

ありがとうございました
32

【ことはじめ】今さら聞けない!? ゼロトラストのきほん (Oracle Cloudウェビナーシリーズ: 2021年2月9日)

【ことはじめ】 今さら聞けない!? ゼロトラストのきほん (Oracle Cloudウェビナーシリーズ: 2021年2月9日)

More Related Content

What's hot

Similar to 【ことはじめ】 今さら聞けない!? ゼロトラストのきほん (Oracle Cloudウェビナーシリーズ: 2021年2月9日)

More from オラクルエンジニア通信

Recently uploaded