• 検索結果がありません。

CI実現に向けた 官民のあり方の見直しについて

N/A
N/A
Protected

Academic year: 2021

シェア "CI実現に向けた 官民のあり方の見直しについて"

Copied!
29
0
0

読み込み中.... (全文を見る)

全文

(1)

“リーズナブルな”プラットフォームの選び方

平 成 3 1 年 1 月

経済産業省CIO補佐官

(2)

Agenda

1

○ クラウドサービスの利用に当たっての考え方

ー 「政府情報システムにおけるクラウドサービスの利用に係る基本方針」の解説

○ 行政手続における本人確認の考え方

ー 国の行政機関のガイドラインの解説

ー 最新グローバルスタンダード

ー 事例紹介:法人共通認証基盤

(3)

クラウドサービスの利用に当たっての考え方

(4)

行政サービスの迅速な立ち上げやスマートフォン等、多様な端末への対応のため、政府システムに

おいても

クラウドサービスを積極的に利用

(クラウド・バイ・デフォルト原則)

テーラーメイドのために、高コスト・柔軟な機能 追加が困難特にレガシーシステムは老朽化・複雑化・ブラッ クボックス化しており、業務停止やデータ流出 など様々なリスクあり2018年6月「政府情報システムにおけるクラウド サービスの利用に係る基本方針」策定クラウド・バイ・デフォルト原則を具体化、各府省が 効果的なクラウドサービスを採用・利用するに当 たっての基本的な考え方を提示

「オンプレミス」から「クラウド」へ

クラウドサービス

(Before)オンプレミス

(After)クラウド

システム導入の 初期費用 サーバ機器の 保守費用 設置場所の費用 や電気料金など の運用費用 ネットワーク機器や ネットワーク運用に かかる費用 管理者の人件費 管理者の人件費 クラウドサービスの 利用料 https://cio.go.jp/sites/default/files/uploads/documents/ cloud_%20policy.pdf 3

(5)

「クラウド・バイ・デフォルト原則」及び基本方針

「クラウド・バイ・デフォルト原則」

・ 「世界最先端IT国家創造宣言・官民データ活用推進基本計画」 (平成29年5月30日閣議決定) ・ 「デジタル・ガバメント推進方針」 (平成29年5月30日高度情報通信ネットワーク社会推進戦略本部・官民 データ活用推進戦略会議決定) ・ 「デジタル・ガバメント実行計画」 (平成30年1月16日eガバメント閣僚会議決定)

クラウドサービスの利用を第一候補とした、

政府情報システムにおけるクラウド・バイ・デフォルトの

基本的な考え方を整理

政府情報システムにおけるクラウドサービスの利用に係る基本方針

クラウド・バイ・デフォルト原則(クラウドサービスの利用を第一候補)

- 政府情報システムは、クラウドサービスの利用を第一候補として、その検討を行う (クラウドサービスにはパブリック及びプライベート(府省共通・府省内の提供する共通基盤等)を含める) - 情報システム化の対象となるサービス・業務、取扱う情報等を明確化した上で、メリット、開発の規模及び 経費等を基に検討を行う

CIO補佐官の関与

- 企画段階及び予算要求段階から、府省CIO補佐官の関与の下で検討を行う 利用検討 フェーズ 導入 フェーズ モニタリング フェーズ 見直し フェーズ 本基本方針

(6)

NISC 統一基準におけるクラウドサービスに関する記述①

 定義

 「クラウドサービス」とは、事業者によって定義されたインタフェースを用いた、

拡張性、柔軟性を持つ共用可能な物理的又は仮想的なリソースにネット

ワーク経由でアクセスするモデルを通じて提供され、利用者によって自由に

リソースの設定・管理が可能なサービスであって、情報セキュリティに関す

る十分な条件設定の余地があるものをいう。

 「約款による外部サービス」とは、民間事業者等の外部の組織が約款に基

づきインターネット上で提供する情報処理サービスであって、当該サービス

を提供するサーバ装置において利用者が情報の作成、保存、送信等を行う

ものをいう。ただし、利用者が必要とする情報セキュリティに関する十分な

条件設定の余地があるものを除く。

5 「政府機関等の対策基準策定のためのガイドライン(平成30年度版) 」より 「政府機関等の情報セキュリティ対策のための統一基準(平成30年度版) 」より

(7)

NISC 統一基準におけるクラウドサービスに関する記述②

 遵守事項

(1) クラウドサービスの利用における対策

• 取り扱う情報の格付及び取扱制限を踏まえ、情報の取扱いを委ねるこ

との可否を判断すること。

• 国内法以外の法令が適用されるリスクを評価して委託先を選定し、必

要に応じて委託事業の実施場所及び契約に定める準拠法・裁判管轄を

指定すること。

• クラウドサービスの中断や終了時に円滑に業務を移行するための対策

を検討し、委託先を選定する際の要件とすること。

• クラウドサービス部分を含む情報の流通経路全般にわたるセキュリティ

が適切に確保されるよう、情報の流通経路全般を見渡した形でセキュリ

ティ設計を行った上でセキュリティ要件を定めること。

• クラウドサービスに対する情報セキュリティ監査による報告書の内容、

各種の認定・認証制度の適用状況等から、クラウドサービス及び当該

サービスの委託先の信頼性が十分であることを総合的・客観的に評価

し判断すること。

(8)

クラウドサービスの利用メリット

7

• 利用者当たりの費用負担、導入時間の短縮

効率性の向上

• 一定水準の情報セキュリティ機能(オンプレミス環境より効率的に情

報セキュリティレベルの向上)

セキュリティ水準の向上

• 新しい機能の随時追加、最新技術の活用

技術革新対応力の向上

• リソース変更の容易性、試行、短期間サービス利用

柔軟性の向上

• 過剰な投資を行うことなく24時間365日の稼働、可用性の向上

可用性の向上

(9)

クラウドサービスの利用検討プロセス

検討準備(Step0)

- 以下の事項を明確化 業務の基本属性、必要なサービスレベル、 サービス・業務の定常性、業務量、取り扱う情報

SaaSの利用検討(Step1、Step2)

- パブリック・クラウドSaaSとプライベート・クラウドのSaaS(政府 共通PF・各府省の共通基盤等が提供)の総合的な検討・評価

IaaS/PaaSの利用検討(Step3、Step4)

- パブリック・クラウドIaaS/PaaSとプライベート・クラウドのIaaS/Paas (政府共通PF・各府省の共通基盤等)の総合的な検討・評価

オンプレミスの利用検討

Step0:検討準備 Step1: SaaS(パブリッククラウド)の利用検討 Step2: SaaS(プライベートクラウド)の利用検討 Step3: IaaS/PaaS(パブリッククラウド)の利用検討 Step4: IaaS/PaaS(プライベートクラウド)の利用検討 オンプレミス(ノン・クラウド) の選択 利用メリットの最大化 規模及び経費の最小化

(10)

具体方針(

Step0:検討準備)

9

業務の基本属性

• 主なサービス利用者(国民向けサービスか、職員向けサービスか)及びその利用者の詳細 • インターネット利用を前提とした業務か否か • サービスの種別(特定の業務か、コミュニケーション系か)等 • 他のサービスやシステムとの連携

必要なサービスレベル

• サービス提供時間 • 障害発生時の復旧許容時間 • 災害対策の要否等

サービス・業務の定常性

• 定常的なサービス・業務か、試行的又は一時的なサービス・業務か

業務量

• 業務処理量の総量、単位時間当たりの処理量の予測 • 業務処理量の変動(増加・減少、ピーク特性等)予測

取り扱う情報

• 府省の情報セキュリティポリシー等に基づいた情報の格付け(機密性、完全性、可用性)、取扱制限 •国の行政機関における業務で取り扱う情報のうち、文書管理ガイドラインに定める秘密文書に相当する機密性を要する 情報を含む情報 •独立行政法人及び指定法人における業務で取り扱う情報のうち、上記に準ずる情報 機密性3情報 「政府機関等の情報セキュリティ対策のための統一基準(平成30年度版) 」より

(11)

パブリック・クラウドとプライベート・クラウドの利用方針

パブリック・クラウドの利用方針

クラウドサービスの選定ポイント - 十分な稼働実績を有し、積極的かつ継続的な投資が行われ、サービス終了のリスクが低いもの - 政府機関の情報セキュリティ対策のための統一基準(以下「統一基準」という。)に定める 「クラウドサービス利用に関する遵守事項」を満たすクラウドサービス - 第三者による認証もしくは監査報告(ISO/IEC27017、CSゴールドマーク、AICPA SOC2等) - 可用性の観点から国内データセンター - バックアップ環境や災害対策環境が、データ同期やバックアップへの切換も含め、標準サービスとして提供 (IaaS/PaaSの場合)  情報セキュリティ - 特定秘密及び極秘文書に該当する情報は取り扱わない - クラウドセキュリティ認証等の認証基準、監査フレームワークの監査報告書から統一基準を満たしていることを確認 - クラウドサービス利用時の伝送路を暗号化。格納されるデータやデータベースについても、機微な情報については暗号化 - 必要があれば、統一基準を満たす情報セキュリティ機能を利用者側で設計・実装(IaaS/PaaSの場合)  クラウドサービスの利用 - クラウドサービス外にもデータをバックアップ - データ移行手段の確保 - 取得可能なログの種類と範囲の確認(SaaSの場合) - 24時間365日の稼働が必要な場合はサービスの冗長化を行い、フェイルオーバーにも備える(IaaS/PaaSの場合)

プライベート・クラウドの利用方針

 府省共通システム、政府共通プラットフォーム、各府省の共通基盤等で提供されるサービスの仕様及び運用ルールに従う (例:人事給与サービス、旅費システム等)

(12)

セキュリティクラウド認証等

11

認証制度

ISO/IEC 27017による認証取得 JASA クラウドセキュリティ推進協議会 CSゴールドマーク 米国 FedRAMP

監査フレームワーク

AICPA SOC2 (日本公認会計士協会IT7号) AICPA SOC3(SysTrust/WebTrsuts)(日本公認 会計士協会IT2号)

Saas(パブリック・クラウド)

 コミュニケーション系:必須、業務系:インフラ部分において、同等のサービスであることが望ましい。

IaaS/PaaS(パブリック・クラウド)

必須

情報セキュリティの確認

認証制度の認証基準、監査フレームワークの監査報告書の活用や個別の調査等により、統一

基準を満たしていることを確認

(13)

行政手続における本人確認の考え方

オンライン手続におけるリスク評価及び電子署名・認証ガイドライン

平成22年8月31日 各府省情報化統括責任者(CIO)連絡会議決定

(14)

13 印 ID/パスワード等 (会員証、運転免許証、弁護士バッジ等のイメージ) 電子署名 (捺印、サイン等のイメージ) 申請書等の文書 相手が誰かを確認する 自身の身元を相手に伝える 文書の作成者が誰かを確認する 自身が作成者であることを示す

「電子認証」と「電子署名」とは

電子認証

(アクセス元の利用者の確認を行うこと) ID/パスワード等を照合 電子署名を検証

電子署名

(文書の作成者の確認を可能とする情報、又はそのような情報を文書に付与する行為のこと)

(15)

14

オンライン手続におけるリスク評価及び電子署名・認証ガイドライン

対象となる 電子手続 対象となる 電子手続 リスクの 影響度 リスクの 影響度 保証 レベル 保証 レベル 対策基準 対策基準 対策例 対策例

オンライン手続におけるリスク評価及び電子署名・認証ガイドライン

電子政府の手続に関わるリスク評価手法、リスクの影響度と対応する保証レベルの考え方

【付録】電子署名・認証の保証レベルに係る対策基準

保証レベルに見合う登録、発行管理、トークン、認証プロトコルの対策基準の考え方 リスクの評価 保証レベル の導出 対策基準 の導出 対策基準 の策定 • 我が国の電子政府における認証方式の設計にあたり活用可能な「ものさし」を確立することを目的として策定。 • ガイドラインは、対象となる電子手続に関するリスク評価手法とこの手法により導出される「リスクの影響度」、 影響度に応じた認証方式の「保証レベル」の導出、各保証レベルに求められる対策基準を規定。

(16)

15

リスクの影響度と保証レベル

「リスク影響度」を「特高」「高」「中」「低」の4段階に定義 いくつかのリスクが想定されるが、オンライン申請等の電子政府サービスにおいては、「機微情報の漏えい」と「金銭 的被害」の2つのリスクが主に発生する可能性があり、この2つのリスクについて影響度の導出方法を定義 特高 高 中 低 中 高 特高 【金銭的損害に係るリスクの影響度】 申請等に係る厳格さ 被害規模 生命の危険又は差別や名 誉毀損等の社会的不利益 につながるもののうち、回復 が困難なもの 【機微情報の漏えいに係るリスクの影響度】 特高 「総合的なリスクの影響度」の導出においては、金銭的損害に係るリスク、機微情報の漏えいに係るリスクのほか、 二次的被害、申請者等の特性、回復可能性など、全ての要素を考慮の上、手続固有の特性を踏まえ導出する。 特高 公知のもの 機微情報ではない 総合的なリスクの影響度 保証レベル 特高 レベル4 高 レベル3 中 レベル2 低 レベル1 「総合的なリスクの影響度」から「保証レベル」を導出する。この保証 レベルに応じた「対策基準」を参照することにより、当該手続のリスクの 影響度に見合った合理的な認証方式の選択が可能となる。

○ リスクの影響度の定義

○ リスクの評価

○ 総合的リスク評価の導出

○ リスク影響度による保証レベルの導出

(17)

16

対策基準

• 各保証レベルに求められる具体的な対応基準を、4つの評価軸ごとに規定 • 対策基準の適用の考え方(※1※2)など、基準実現のための配慮事項についても規定 保証 レベル 登録 発行・管理 トークン 認証プロセス 署名等プロセス レベル4 (窓口) •写真付き身分証明1種の提示 •申請情報の台帳照合 •重複登録ではないことの確認 •手渡し、本人限定受 取郵便、によるトークン 発行 •レベル3の基準に加え、 耐タンパ性が確保され たハードウェアトークンを 利用すること •レベル3と同等の基準 •電子政府推奨暗号リス トに記載の署名方式 •電子署名用の証明書の 用途は電子署名限定 レベル3 (窓口) •写真付き身分証明1種(or他2種)の提示 •申請情報の台帳(又は公的証明書)照合 (郵送 or オンライン) •申請書に対する電子署名 •申請情報の台帳(又は公的証明書)照合 •レベル4の方法に加え、 書留郵便、書留郵便 +ダウンロード、電子 署名+ダウンロード、に よるトークン発行 •レベル2の基準に加え、 複数の認証要素を利 用すること •レベル2と同等の基準 に加え、フィッシングの脅 威に対する耐性 •電子政府推奨暗号リス トに記載の署名方式 レベル2 (窓口) •写真付き身分証明1種(or他2種)の提示 (郵送 or オンライン) •申請情報に他機関の登録情報(クレジット カード番号等)を含めて申告 •レベル3の方法に加え、 分割配付(一方を郵 送)、メール通知後の ダウンロード、によるトー クン発行 •認証情報の推測確率 が16384分の1 未満であること •レベル1と同等の基準に 加え、盗聴、セッション・ ハイジャック、中間者攻 撃の脅威に対する耐性 レベル1 (窓口 or 郵送 or オンライン) •身元確認は不要 •メールアドレスの到達確認 •レベル2の発行方法に 加え、電子メールによる 送付、ダウンロード、に よるトークン発行 •認証情報の推測確率 が1024分の1未 満であること •オンライン上の推測、リ プレイ攻撃の脅威に対 する耐性 <主な対策基準> ※1 上位基準の採用:認証方式の強度とコスト及び利便性は一般的にトレードオフの関係にありコストや利便性等の多様な観点による総合的な判断が必要となる ※2 代替基準の採用:ガイドラインの対策基準は絶対的なものではなく、同等の代替基準であれば他の対応策による代替が許容される

(18)

行政手続における本人確認の考え方

最新のグローバルスタンダード(NIST SP800-63-3)

(19)

18

電子認証のグローバルスタンダードの変遷

公開年月

タイトル

SP800-63-1

2011-12

Electronic Authentication Guideline

SP800-63-2

2013-08

Electronic Authentication Guideline

SP800-63-3

SP800-63-3A

SP800-63-3B

SP800-63-3C

2017-06

Digital Identity Guidelines

Enrollment and Identity Proofing

Authentication and Lifecycle Management

Federation and Assertions

登録

発行・管理

トークン

認証プロセス

身元確認(Identity Proofing) 当人認証(Auhtentication)

認証連携(Federation)

SP800-63-1、SP800-63-2

(20)

NIST SP800-63-3 Digital Identity Guidelines (2017)

19 IALレベル 内容 IAL 3 対面での身元情報の確認が要求される。身元を識別する属性は、訓練を受けた上で認可された組織の 担当者によって検証が必要。 IAL 2 主張された身元情報が現実に存在することを確認し、申請者がその実在する身元情報に適切に関連付 けられていることを検証できる証拠が必要。IAL2ではリモート(遠隔)か対面での身元情報の確 認が必要。 IAL 1 申請者を特定の現実の身元情報と関連付ける必要はない。認証プロセスに関連して提供されるいかな る属性も自己表明か自己表明相当。 AALレベル 内容 AAL 3 認証要求者が加入者のアカウントに結び付けられた認証コードを管理していることが、非常に高い確 信度で保証されるレベル。 AAL3は、AAL2に加え、ハードウェアベースの認証コードと検証者に偽装耐性を提供する認証 コードを使用し、暗号プロトコルによる鍵の所有の証明することが必要。また、承認済みの暗号化技 術が要求される。 AAL 2 認証要求者が加入者のアカウントに結び付けられた認証コードを管理していることが、高い確信度で 保証されるレベル。 AAL2は、複数要素の認証コードを保持し管理していることをセキュアな認証プロトコルによって 証明することが必要。また、承認済みの暗号化技術が要求される。 AAL 1 認証要求者が加入者のアカウントに結び付けられた認証コードを管理していることが、ある程度の確 信度で保証されるレベル。 AAL1は、単要素か複数要素の認証コードを保持し管理していることをセキュアな認証プロトコル によって証明することが必要。

Identity Assurance Level

(身元確認保証レベル)

(21)

行政手続における本人確認の考え方

事例紹介:法人共通認証基盤

(22)

法人デジタルプラットフォーム(全体像)

21

事業者の認証

補助金

申請

計画認定

許認可

届出

データA

データB

データC

データD

手続システム (手続を処理)

法人共通認証基盤

(ログインシステム)

データベース (データを蓄積)

データ交換プラットフォーム API API API API

API API API API

オープンデータ (民間向けデータの開放) • 経産省では、行政手続等のデジタル化を効果的に進め、かつデータを十分に活用できる環境 を構築するため、アーキテクチャーを整理し、共通的に必要な機能と個別業務で必要な機能 に分けて開発を進めている。(法人デジタルプラットフォーム) • 法人版マイナンバーである法人番号を活用し、一つのID/パスワードで複数の行政サービス にアクセスでき、ワンスオンリーが可能となる認証システムとして「法人共通認証基盤」を 整備。

(23)

ン) デー

経産省による法人行政手続のデジタルプラットフォーム構築

オー デー

法人データ

交換基盤

各行政手続

システム

法人デジタルプラットフォーム

法人インフォ

メーション

法人共通

認証基盤

2018年度 開発 2018年度より開発 2019年度より試行予定 2017年度より運用

経産省が法人手続デジタル化に必要なインフラを構築

22

(24)

23

(参考)デジタル・ガバメント実行計画

(平成30年7月 デジタル・ガバメント閣僚会議決定)

【デジタルファースト】 【ワンスオンリー】 【ワンストップ】 ■ 行政手続における添付書類の撤廃  マイナンバー制度等を活用し、既に行政が保有している情 報は、添付書類の提出を一括して撤廃  添付書類を一括して撤廃するための法案を可能な限り速 やかに国会に提出 • 登記事項証明書、住民票の写し・戸籍謄抄本等の提 出不要化  各種手続のオンライン原則の徹底  手続毎に業務改革(BPR)、システム改革を実施の上、 行政サービスのデジタル化を徹底する  押印や対面等の本人確認等手法の在り方を再整理  多様な端末で利用な文字環境の在り方を再整理  民-民手続についてもオンライン化に向けた見直しを実施 【個別分野におけるサービス改革】各府省のITガバナンスを強化し、各種取組を推進するため、各府省におけるデジタル改革の中長期計画を平成30年上半期を目途に策定 【各府省中長期計画の策定】  「行政手続等の棚卸」等を踏まえ、個別分野で先行的にサービス改革を推進 各府省計画の策定と個別分野のサービス改革 横断的施策による「行政サービス改革」の推進 (1) 行政サービスの100%デジタル化 ■ オープンデータ・バイ・デザインの推進  オープンデータを前提とした業務・システムの設計・運用の推進 ■ ニーズの把握と迅速な公開  民間事業者等との直接対話を通じた民間ニーズの把握とこれに 対応したオープン化の加速  推奨データセットに基づくデータ公開の推進 【政府情報システム改革の着実な推進】  これまでの取組により、約1,118億円の運用コストの削減を見込んでいる。改革を引き続き推進し、システム数の半減、運用コストの3割削減を達成 (2) 行政保有データの100%オープン化 (3) デジタル改革の基盤整備 【オープンデータの推進】 【行政データ標準の確立】 【法人デジタルプラットフォームの構築】 ■ 民間サービスとの連携も含めたワンストップ化を推進  主要ライフイベントである以下を先行分野として推進 • 引越し,介護,死亡・相続 ■ 行政データ連携標準の策定  日付・住所等のコアとなる行政データ形式について、平成29年度末 までにデータ連携の標準を策定 ■ 語彙・コード・文字等の標準化、環境整備  施設・設備・調達等の社会基盤となる分野について、語彙・コード 等の体系を共通語彙基盤として整理  データ品質まで含んだデータ活用、流通のルールを整理  複数手続を一つのIDで申請できる認証システムの整備や法人インフォ メーションの活用等を通じ、データが官民で有効活用される基盤を構築

(25)

法人共通認証基盤の概要

事業者にとって、複数のID/パスワードを管理することは非常に煩雑。

また、複数の制度・手続でID発行のために代表者確認を行うことは、非合理的であり、かつ事業者に

とっても負担。

⇒ 1つのID/パスワードでの手続の実現により、

官民双方における手続に要する時間やコストを削減

24

《法人共通認証基盤のイメージ》

これから:1つのID/パスワードで手続を可能に

手続A

手続B

手続C

手続A

手続B

手続C

管理 が煩雑 法人共通認証基盤

これまで:複数のID/パスワードが必要

さらに、法人共通認証基盤を含む法人デジタルプラットフォームの構築により、ワンスオンリー

(同じ情報の入力は一度だけ)や、より精緻なデータ分析・活用を可能に。

(26)

利用できるアカウントの種別

法人共通認証基盤では

①法人基本3情報の厳密な確認を行わず発行するアカウント

及び

②初回

のみ法人基本3情報を正確に確認し発行するアカウント

の、2系統を提供。

各行政手続における身元確認の要否により、いずれのアカウントを使用するかが手続ごとに設定される。

25

gBizエントリー

gBizプライム

gBizメンバー

・法人代表者の厳格な確認は行わずオンラインで発行

・ID/パスワードを用いた

単要素認証

を行う

変更可

・印鑑証明書及び登録印から法人代表者であることの確認を行い発行

・ID/パスワードに加え、所有物認証による

二要素認証

を行う

・組織の従業員用のアカウントとして、gBizプライムが発行

・ID/パスワードに加え、所有物認証による

二要素認証

を行う

《法人共通認証基盤(GビジネスID(※))のアカウント体系》

※ 法人共通認証基盤のサービス名称として、「GビジネスID」という名称を用いる予定。 ※ 法人共通認証基盤は、法人のほか、個人事業主も利用可能。

(27)

NIST SP 800-63-3(アメリカ国立標準技術研究所(NIST)が定

める電子的認証に関するガイドライン)の各ユーザモデルの保証レベルと、

法人共通認証基盤との関係については、以下のとおり整理。

gBizエントリー

gBizプライム

IAL

身元情報検証時の保証

レベル

(Identity Assurance

Level)

本人確認不要、自己申告での

登録でよい

サービス内容により識別に用いられる属

性をリモート又は対面で確認する必要

あり

AAL

認証プロセスの保証レベル

(Authenticator

Assurance Level)

単要素認証でOK

2要素認証が必要(2要素目の認証

手段はソフトウェアベースのものでOK)

26

保証レベル(NIST SP 800-63-3との関係)

(28)

スマートフォンアプリ認証

ワンタイムパスワード認証

・アカウント登録後、マイページからスマホアプリのダウンロードが可能。 ・スマホアプリ登録後は、パスワード認証後、スマホアプリでOKボ タンを押下する、又は指紋認証、又は顔認証(機種や設定によ り異なる)をしてログイン。 ・アプリケーションは、iPhone及びAndorid端末に対して提供す る。iPhoneのうち、TouchIDやFaceIDに対応している端末の場 合には、指紋認証や顔認証を利用することができる。 ・また、iOSの生体認証(TouchID/FaceID)が失敗した場合 は以下のとおりとなる。 -PIN認証が有効な場合:PIN認証画面を表示 -PIN認証が無効な場合:ボタン認証画面を表示 ・スマートフォンアプリの利用ができない場合は、 ワンタイムパスワード認証を利用。 ・ユーザ登録時に登録したSMS受信用電話 番号に、SMSにてワンタイムパスワード(6桁 数字)を送信する。 ・利用者はそのワンタイムパスワードをWeb 画面上で入力することでログインできる。 ・ワンタイムパスワードの有効期限は1時間。 (左図) ボタン認証の場合 (右図) 指紋認証の場合 アイコン 画面入力 27

所有物認証の詳細について

SMSにて受信 ワンタイムパスワード: (例)123456 (イメージ)

(29)

ン) デー 理) デー

デジタルガバメントアーキテクチャの整備

オー デー 28 データ蓄積・通信リソース (クラウドサービス) デジタルガバメントアーキテクチャ • デジタルガバメントを俯瞰し、リーズナブルなコンポーネントとして整理することが重要 • コンポーネントは、リーズナブルな標準技術、成熟した技術を適用することが重要 (独創的、独自技術は、リーズナブルでない場合が多い。) • 技術革新が激しい状況においては、リーズナブルな技術選択ライフサイクルが重要 (これまでは、十分成熟しきった技術活用がリスクが少なかった。近年は、成熟する時期 自体を見極めなければリスクとなる。) データ語彙 (データフォーマット)

参照

関連したドキュメント

第2章 環境影響評価の実施手順等 第1

当面の間 (メタネーション等の技術の実用化が期待される2030年頃まで) は、本制度において

観察を通じて、 NSOO

接続対象計画差対応補給電力量は,30分ごとの接続対象電力量がその 30分における接続対象計画電力量を上回る場合に,30分ごとに,次の式

接続対象計画差対応補給電力量は,30分ごとの接続対象電力量がその 30分における接続対象計画電力量を上回る場合に,30分ごとに,次の式

行ない難いことを当然予想している制度であり︑

なお,今回の申請対象は D/G に接続する電気盤に対する HEAF 対策であるが,本資料では前回 の HEAF 対策(外部電源の給電時における非常用所内電源系統の電気盤に対する

点検方法を策定するにあたり、原子力発電所耐震設計技術指針における機