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

平 成 3 １ 年 1 月経済産業省CIO補佐官満 塩 尚 史

Agenda

1

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

○ 行政手続における本人確認の考え方ー 国の行政機関のガイドラインの解説ー 最新グローバルスタンダードー 事例紹介：法人共通認証基盤

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

2

• 行政サービスの迅速な立ち上げやスマートフォン等、多様な端末への対応のため、政府システムにおいてもクラウドサービスを積極的に利用（クラウド・バイ・デフォルト原則）

テーラーメイドのために、高コスト・柔軟な機能追加が困難

特にレガシーシステムは老朽化・複雑化・ブラックボックス化しており、業務停止やデータ流出など様々なリスクあり

2018年6月「政府情報システムにおけるクラウドサービスの利用に係る基本方針」策定

クラウド・バイ・デフォルト原則を具体化、各府省が効果的なクラウドサービスを採用・利用するに当たっての基本的な考え方を提示

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

クラウドサービス

（Before）オンプレミス （After）クラウド

システム導入の初期費用サーバ機器の保守費用

設置場所の費用や電気料金などの運用費用

ネットワーク機器やネットワーク運用にかかる費用

管理者の人件費管理者の人件費

クラウドサービスの利用料

https://cio.go.jp/sites/default/files/uploads/documents/cloud_%20policy.pdf 3

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

4

「クラウド・バイ・デフォルト原則」・ 「世界最先端ＩＴ国家創造宣言・官民データ活用推進基本計画」

（平成29年5月30日閣議決定）・ 「デジタル・ガバメント推進方針」

（平成29年5月30日高度情報通信ネットワーク社会推進戦略本部・官民データ活用推進戦略会議決定）

・ 「デジタル・ガバメント実行計画」（平成30年1月16日eガバメント閣僚会議決定）

クラウドサービスの利用を第一候補とした、政府情報システムにおけるクラウド・バイ・デフォルトの

基本的な考え方を整理

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

クラウド・バイ・デフォルト原則（クラウドサービスの利用を第一候補）－ 政府情報システムは、クラウドサービスの利用を第一候補として、その検討を行う

（クラウドサービスにはパブリック及びプライベート（府省共通・府省内の提供する共通基盤等）を含める）－ 情報システム化の対象となるサービス・業務、取扱う情報等を明確化した上で、メリット、開発の規模及び

経費等を基に検討を行う CIO補佐官の関与－ 企画段階及び予算要求段階から、府省CIO補佐官の関与の下で検討を行う

利用検討フェーズ

導入フェーズ

モニタリングフェーズ

見直しフェーズ

本基本方針

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

定義

「クラウドサービス」とは、事業者によって定義されたインタフェースを用いた、拡張性、柔軟性を持つ共用可能な物理的又は仮想的なリソースにネットワーク経由でアクセスするモデルを通じて提供され、利用者によって自由にリソースの設定・管理が可能なサービスであって、情報セキュリティに関する十分な条件設定の余地があるものをいう。

「約款による外部サービス」とは、民間事業者等の外部の組織が約款に基づきインターネット上で提供する情報処理サービスであって、当該サービスを提供するサーバ装置において利用者が情報の作成、保存、送信等を行うものをいう。ただし、利用者が必要とする情報セキュリティに関する十分な条件設定の余地があるものを除く。

5「政府機関等の対策基準策定のためのガイドライン（平成30年度版） 」より

「政府機関等の情報セキュリティ対策のための統一基準（平成30年度版） 」より

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

遵守事項

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

• 取り扱う情報の格付及び取扱制限を踏まえ、情報の取扱いを委ねることの可否を判断すること。

• 国内法以外の法令が適用されるリスクを評価して委託先を選定し、必要に応じて委託事業の実施場所及び契約に定める準拠法・裁判管轄を指定すること。

• クラウドサービスの中断や終了時に円滑に業務を移行するための対策を検討し、委託先を選定する際の要件とすること。

• クラウドサービス部分を含む情報の流通経路全般にわたるセキュリティが適切に確保されるよう、情報の流通経路全般を見渡した形でセキュリティ設計を行った上でセキュリティ要件を定めること。

• クラウドサービスに対する情報セキュリティ監査による報告書の内容、各種の認定・認証制度の適用状況等から、クラウドサービス及び当該サービスの委託先の信頼性が十分であることを総合的・客観的に評価し判断すること。

6

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

7

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

効率性の向上

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

セキュリティ水準の向上

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

技術革新対応力の向上

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

柔軟性の向上

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

可用性の向上

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

8

検討準備（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（プライベートクラウド）の利用検討

オンプレミス（ノン・クラウド）の選択

利用メリットの最大化

規模及び経費の最小化

具体方針（Step0:検討準備）

9

業務の基本属性

• 主なサービス利用者（国民向けサービスか、職員向けサービスか）及びその利用者の詳細

• インターネット利用を前提とした業務か否か

• サービスの種別（特定の業務か、コミュニケーション系か）等

• 他のサービスやシステムとの連携

必要なサービスレベル

• サービス提供時間

• 障害発生時の復旧許容時間

• 災害対策の要否等

サービス・業務の定常性

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

業務量

• 業務処理量の総量、単位時間当たりの処理量の予測

• 業務処理量の変動（増加・減少、ピーク特性等）予測

取り扱う情報

• 府省の情報セキュリティポリシー等に基づいた情報の格付け（機密性、完全性、可用性）、取扱制限

•国の行政機関における業務で取り扱う情報のうち、文書管理ガイドラインに定める秘密文書に相当する機密性を要する情報を含む情報

•独立行政法人及び指定法人における業務で取り扱う情報のうち、上記に準ずる情報

機密性3情報

「政府機関等の情報セキュリティ対策のための統一基準（平成30年度版） 」より

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

10

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

クラウドサービスの選定ポイント－ 十分な稼働実績を有し、積極的かつ継続的な投資が行われ、サービス終了のリスクが低いもの－ 政府機関の情報セキュリティ対策のための統一基準（以下「統一基準」という。）に定める

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

プライベート・クラウドの利用方針 府省共通システム、政府共通プラットフォーム、各府省の共通基盤等で提供されるサービスの仕様及び運用ルールに従う

（例：人事給与サービス、旅費システム等）

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

11

認証制度

ISO/IEC 27017による認証取得

JASAクラウドセキュリティ推進協議会

CSゴールドマーク

米国 FedRAMP

監査フレームワーク

AICPA SOC2（日本公認会計士協会 IT7号）

AICPA SOC3（SysTrust/WebTrsuts）（日本公認会計士協会 IT2号）

Saas（パブリック・クラウド） コミュニケーション系：必須、業務系：インフラ部分において、同等のサービスであることが望ましい。

IaaS/PaaS（パブリック・クラウド） 必須

情報セキュリティの確認 認証制度の認証基準、監査フレームワークの監査報告書の活用や個別の調査等により、統一基準を満たしていることを確認

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

オンライン手続におけるリスク評価及び電子署名・認証ガイドライン平成22年8月31日 各府省情報化統括責任者（CIO）連絡会議決定

12

13

印

ID/パスワード等（会員証、運転免許証、弁護士バッジ等のイメージ）

電子署名（捺印、サイン等のイメージ）

申請書等の文書

相手が誰かを確認する自身の身元を相手に伝える

文書の作成者が誰かを確認する自身が作成者であることを示す

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

電子認証 （アクセス元の利用者の確認を行うこと）

ID/パスワード等を照合

電子署名を検証

電子署名 （文書の作成者の確認を可能とする情報、又はそのような情報を文書に付与する行為のこと）

14

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

対象となる電子手続対象となる電子手続

リスクの影響度リスクの影響度

保証レベル保証レベル

対策基準対策基準対策例対策例

オンライン手続におけるリスク評価及び電子署名・認証ガイドライン電子政府の手続に関わるリスク評価手法、リスクの影響度と対応する保証レベルの考え方

【付録】電子署名・認証の保証レベルに係る対策基準保証レベルに見合う登録、発行管理、トークン、認証プロトコルの対策基準の考え方

リスクの評価 保証レベルの導出

対策基準の導出

対策基準の策定

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

15

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

「リスク影響度」を「特高」「高」「中」「低」の4段階に定義

いくつかのリスクが想定されるが、オンライン申請等の電子政府サービスにおいては、「機微情報の漏えい」と「金銭的被害」の２つのリスクが主に発生する可能性があり、この２つのリスクについて影響度の導出方法を定義

特高

高

中

低 中 高 特高

【金銭的損害に係るリスクの影響度】

申請等に係る厳格さ

被害規模

生命の危険又は差別や名誉毀損等の社会的不利益につながるもののうち、回復が困難なもの

【機微情報の漏えいに係るリスクの影響度】

低

特高

「総合的なリスクの影響度」の導出においては、金銭的損害に係るリスク、機微情報の漏えいに係るリスクのほか、二次的被害、申請者等の特性、回復可能性など、全ての要素を考慮の上、手続固有の特性を踏まえ導出する。

低

特高

公知のもの

機微情報ではない

総合的なリスクの影響度 保証レベル特高 レベル４高 レベル３中 レベル２低 レベル１

「総合的なリスクの影響度」から「保証レベル」を導出する。この保証レベルに応じた「対策基準」を参照することにより、当該手続のリスクの影響度に見合った合理的な認証方式の選択が可能となる。

○ リスクの影響度の定義

○ リスクの評価

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

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

16

対策基準• 各保証レベルに求められる具体的な対応基準を、４つの評価軸ごとに規定• 対策基準の適用の考え方（※１※２）など、基準実現のための配慮事項についても規定

保証レベル 登録 発行・管理 トークン 認証プロセス 署名等プロセス

レベル４ （窓口）• 写真付き身分証明1種の提示• 申請情報の台帳照合• 重複登録ではないことの確認

• 手渡し、本人限定受取郵便、によるトークン発行

• レベル3の基準に加え、耐タンパ性が確保されたハードウェアトークンを利用すること

• レベル３と同等の基準 • 電子政府推奨暗号リストに記載の署名方式

• 電子署名用の証明書の用途は電子署名限定

レベル３ （窓口）• 写真付き身分証明1種（or他2種）の提示• 申請情報の台帳（又は公的証明書）照合（郵送 or オンライン）• 申請書に対する電子署名• 申請情報の台帳（又は公的証明書）照合

• レベル4の方法に加え、書留郵便、書留郵便＋ダウンロード、電子署名＋ダウンロード、によるトークン発行

• レベル2の基準に加え、複数の認証要素を利用すること

• レベル２と同等の基準に加え、フィッシングの脅威に対する耐性

• 電子政府推奨暗号リストに記載の署名方式

レベル２ （窓口）• 写真付き身分証明1種（or他2種）の提示（郵送 or オンライン）• 申請情報に他機関の登録情報（クレジットカード番号等）を含めて申告

• レベル3の方法に加え、分割配付（一方を郵送）、メール通知後のダウンロード、によるトークン発行

• 認証情報の推測確率が１６３８４分の１未満であること

• レベル1と同等の基準に加え、盗聴、セッション・ハイジャック、中間者攻撃の脅威に対する耐性

レベル１ （窓口 or 郵送 or オンライン）• 身元確認は不要• メールアドレスの到達確認

• レベル2の発行方法に加え、電子メールによる送付、ダウンロード、によるトークン発行

• 認証情報の推測確率が１０２４分の１未満であること

• オンライン上の推測、リプレイ攻撃の脅威に対する耐性

＜主な対策基準＞

※１ 上位基準の採用：認証方式の強度とコスト及び利便性は一般的にトレードオフの関係にありコストや利便性等の多様な観点による総合的な判断が必要となる※２ 代替基準の採用：ガイドラインの対策基準は絶対的なものではなく、同等の代替基準であれば他の対応策による代替が許容される

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

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

17

18

電子認証のグローバルスタンダードの変遷公開年月 タイトル

SP800-63-1 2011-12 Electronic Authentication GuidelineSP800-63-2 2013-08 Electronic Authentication GuidelineSP800-63-3SP800-63-3ASP800-63-3BSP800-63-3C

2017-06 Digital Identity GuidelinesEnrollment and Identity ProofingAuthentication and Lifecycle ManagementFederation and Assertions

登録 発行・管理 トークン 認証プロセス

身元確認（Identity Proofing） 当人認証（Auhtentication）

認証連携（Federation）

SP800-63-1、SP800-63-2

SP800-63-3

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

19

IALレベル 内容

IAL 3 対面での身元情報の確認が要求される。身元を識別する属性は、訓練を受けた上で認可された組織の担当者によって検証が必要。

IAL 2 主張された身元情報が現実に存在することを確認し、申請者がその実在する身元情報に適切に関連付けられていることを検証できる証拠が必要。ＩＡＬ２ではリモート（遠隔）か対面での身元情報の確認が必要。

IAL 1 申請者を特定の現実の身元情報と関連付ける必要はない。認証プロセスに関連して提供されるいかなる属性も自己表明か自己表明相当。

AALレベル 内容

AAL 3 認証要求者が加入者のアカウントに結び付けられた認証コードを管理していることが、非常に高い確信度で保証されるレベル。ＡＡＬ３は、ＡＡＬ２に加え、ハードウェアベースの認証コードと検証者に偽装耐性を提供する認証コードを使用し、暗号プロトコルによる鍵の所有の証明することが必要。また、承認済みの暗号化技術が要求される。

AAL 2 認証要求者が加入者のアカウントに結び付けられた認証コードを管理していることが、高い確信度で保証されるレベル。ＡＡＬ２は、複数要素の認証コードを保持し管理していることをセキュアな認証プロトコルによって証明することが必要。また、承認済みの暗号化技術が要求される。

AAL 1 認証要求者が加入者のアカウントに結び付けられた認証コードを管理していることが、ある程度の確信度で保証されるレベル。ＡＡＬ１は、単要素か複数要素の認証コードを保持し管理していることをセキュアな認証プロトコルによって証明することが必要。

Identity Assurance Level（身元確認保証レベル）

Authentication Assurance Level（当人認証保証レベル）

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

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

20

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

21

事業者の認証

補助金申請 計画認定 許認可 届出

データA データB データC データD

手続システム（手続を処理）

法人共通認証基盤（ログインシステム）

データベース（データを蓄積）

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

API API API APIオープンデータ（民間向けデータの開放）

• 経産省では、行政手続等のデジタル化を効果的に進め、かつデータを十分に活用できる環境を構築するため、アーキテクチャーを整理し、共通的に必要な機能と個別業務で必要な機能に分けて開発を進めている。（法人デジタルプラットフォーム）

• 法人版マイナンバーである法人番号を活用し、一つのID/パスワードで複数の行政サービスにアクセスでき、ワンスオンリーが可能となる認証システムとして「法人共通認証基盤」を整備。

事業者の認証

（ログイン）

電子申請

データ連携

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

オープンデータ

法人データ交換基盤

各行政手続システム

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

国民・事業者

国民・事業者

法人インフォメーション

法人共通認証基盤2018年度

開発2018年度より

開発2019年度より

試行予定2017年度より運用

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

23

（参考）デジタル・ガバメント実行計画（平成30年7月 デジタル・ガバメント閣僚会議決定）

【デジタルファースト】

【ワンスオンリー】

【ワンストップ】

■ 行政手続における添付書類の撤廃 マイナンバー制度等を活用し、既に行政が保有している情

報は、添付書類の提出を一括して撤廃 添付書類を一括して撤廃するための法案を可能な限り速

やかに国会に提出• 登記事項証明書、住民票の写し・戸籍謄抄本等の提

出不要化

各種手続のオンライン原則の徹底 手続毎に業務改革（BPR）、システム改革を実施の上、

行政サービスのデジタル化を徹底する 押印や対面等の本人確認等手法の在り方を再整理 多様な端末で利用な文字環境の在り方を再整理 民－民手続についてもオンライン化に向けた見直しを実施

【個別分野におけるサービス改革】各府省のITガバナンスを強化し、各種取組を推進するため、各府省におけるデジタル改革の中長期計画を平成30年上半期を目途に策定

【各府省中長期計画の策定】

「行政手続等の棚卸」等を踏まえ、個別分野で先行的にサービス改革を推進

各府省計画の策定と個別分野のサービス改革

横断的施策による「行政サービス改革」の推進(1) 行政サービスの100％デジタル化

■ オープンデータ・バイ・デザインの推進 オープンデータを前提とした業務・システムの設計・運用の推進■ ニーズの把握と迅速な公開 民間事業者等との直接対話を通じた民間ニーズの把握とこれに

対応したオープン化の加速 推奨データセットに基づくデータ公開の推進

【政府情報システム改革の着実な推進】 これまでの取組により、約1,118億円の運用コストの削減を見込んでいる。改革を引き続き推進し、システム数の半減、運用コストの３割削減を達成

(2) 行政保有データの100％オープン化

(3) デジタル改革の基盤整備

【オープンデータの推進】

【行政データ標準の確立】

【法人デジタルプラットフォームの構築】■ 民間サービスとの連携も含めたワンストップ化を推進 主要ライフイベントである以下を先行分野として推進

• 引越し，介護，死亡・相続

■ 行政データ連携標準の策定 日付・住所等のコアとなる行政データ形式について、平成29年度末

までにデータ連携の標準を策定■ 語彙・コード・文字等の標準化、環境整備 施設・設備・調達等の社会基盤となる分野について、語彙・コード

等の体系を共通語彙基盤として整理 データ品質まで含んだデータ活用、流通のルールを整理

複数手続を一つのIDで申請できる認証システムの整備や法人インフォメーションの活用等を通じ、データが官民で有効活用される基盤を構築

法人共通認証基盤の概要• 事業者にとって、複数のID/パスワードを管理することは非常に煩雑。• また、複数の制度・手続でID発行のために代表者確認を行うことは、非合理的であり、かつ事業者にとっても負担。

⇒ １つのID/パスワードでの手続の実現により、官民双方における手続に要する時間やコストを削減。

24

《法人共通認証基盤のイメージ》これから：1つのID/パスワードで手続を可能に

手続A

手続B

手続C

手続A

手続B

手続C

管理が煩雑

法人共通認証基盤

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

さらに、法人共通認証基盤を含む法人デジタルプラットフォームの構築により、ワンスオンリー（同じ情報の入力は一度だけ）や、より精緻なデータ分析・活用を可能に。

利用できるアカウントの種別• 法人共通認証基盤では①法人基本3情報の厳密な確認を行わず発行するアカウント及び②初回

のみ法人基本3情報を正確に確認し発行するアカウントの、２系統を提供。• 各行政手続における身元確認の要否により、いずれのアカウントを使用するかが手続ごとに設定される。

25

gBizエントリー

gBizプライム

gBizメンバー

・法人代表者の厳格な確認は行わずオンラインで発行・ID/パスワードを用いた単要素認証を行う

変更可

・印鑑証明書及び登録印から法人代表者であることの確認を行い発行・ID/パスワードに加え、所有物認証による二要素認証を行う

・組織の従業員用のアカウントとして、gBizプライムが発行・ID/パスワードに加え、所有物認証による二要素認証を行う

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

１

２

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

NIST SP 800-63-3（アメリカ国立標準技術研究所（NIST）が定める電子的認証に関するガイドライン）の各ユーザモデルの保証レベルと、法人共通認証基盤との関係については、以下のとおり整理。

gBizエントリー gBizプライム

IAL身元情報検証時の保証レベル(Identity Assurance Level)

１ ２

本人確認不要、自己申告での登録でよい

サービス内容により識別に用いられる属性をリモート又は対面で確認する必要あり

AAL認証プロセスの保証レベル(Authenticator Assurance Level)

１ ２

単要素認証でOK ２要素認証が必要（2要素目の認証手段はソフトウェアベースのものでOK）

26

保証レベル（NIST SP 800-63-3との関係）

スマートフォンアプリ認証 ワンタイムパスワード認証

・アカウント登録後、マイページからスマホアプリのダウンロードが可能。・スマホアプリ登録後は、パスワード認証後、スマホアプリでOKボタンを押下する、又は指紋認証、又は顔認証（機種や設定により異なる）をしてログイン。・アプリケーションは、iPhone及びAndorid端末に対して提供する。iPhoneのうち、TouchIDやFaceIDに対応している端末の場合には、指紋認証や顔認証を利用することができる。・また、iOSの生体認証（TouchID/FaceID）が失敗した場合は以下のとおりとなる。－PIN認証が有効な場合：PIN認証画面を表示－PIN認証が無効な場合：ボタン認証画面を表示

・スマートフォンアプリの利用ができない場合は、ワンタイムパスワード認証を利用。・ユーザ登録時に登録したSMS受信用電話番号に、SMSにてワンタイムパスワード（6桁数字）を送信する。・利用者はそのワンタイムパスワードをWeb画面上で入力することでログインできる。・ワンタイムパスワードの有効期限は1時間。

（左図）ボタン認証の場合（右図）指紋認証の場合

アイコン画面入力

27

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

SMSにて受信ワンタイムパスワード：

(例)123456

（イメージ）

事業者の認証

（ログイン）

電子申請

（データ処理）

データ連携

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

オープンデータ

国民・事業者

国民・事業者

28

データ蓄積・通信リソース（クラウドサービス）

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

• デジタルガバメントを俯瞰し、リーズナブルなコンポーネントとして整理することが重要• コンポーネントは、リーズナブルな標準技術、成熟した技術を適用することが重要（独創的、独自技術は、リーズナブルでない場合が多い。）

• 技術革新が激しい状況においては、リーズナブルな技術選択ライフサイクルが重要（これまでは、十分成熟しきった技術活用がリスクが少なかった。近年は、成熟する時期自体を見極めなければリスクとなる。）

データ語彙（データフォーマット）