リファレンスアーキテクチャ（第5章 AWS）
2023/11/02 公開
5. ブロック実現例（AWS）
「ブロック一覧」で挙げた業務ブロック、非機能ブロックを実現するためのAWS版サンプル構成を本章にて示す。
サンプル構成を参考にし、刷新対象システムの要件に合わせて実際に採用するサービスや統合するサービス等を検討いただきたい。
5-1. 業務ブロック
5-1-1. 利用者認証
- 行政システムのオンライン利用のため、公的個人認証サービスを用いて保証レベルAでの本人確認を行う。
- 利用者の本人確認(レベルA※)を行う業務
- 利用者の情報を管理する業務
- 認証前のトップ画面を表示
- コンテンツ管理_Webページ(静的コンテンツ)公開機能
- 利用者の当人認証を要する機能
- 申請・届出_申請・届出機能
- コンテンツ管理_Webページ(動的コンテンツ)公開機能 など
- 本人確認の保証レベルがレベルAの場合には、公的個人認証サービスと連携し、マイナンバーカードに搭載された電子証明書によって利用者の身元確認と当人認証を行う手法がガイドラインで示されている。身元確認(ID作成)では、署名用証明書を用い、4情報(住所、氏名、生年月日、性別)を取得し、また、当人認証(システム利用)では、利用者証明証証明を用いることを想定している。
- 利用者は、スマホ等の端末で電子証明書に設定したPIN/パスワードを入力し、マイナンバーカードの読み取りを行う。
- Amazon Cognitoのユーザプールの機能を使用し、公的個人認証サービスによって認証されたユーザに対するトークンを発行する。
- ユーザ情報を管理するためのWebAPIはAPI Gatewayにより構築される。
- API GatewayはAmazon CognitoをWebAPIの呼び出し可否の判断に使用するオーソライザーとして連携が可能である。
- Amazon Cognitoをオーソライザーとして設定することで、トークンの有効性確認の処理をAPI Gatewayに任せることができる。
- また、WAFによりインターネット経由で行われる様々な攻撃からAPIを保護する。
- Amazon DocumentDBに格納されたユーザ情報に対して、AWS Lambdaから新規作成や更新等の管理を行う。
- 行政システムのオンライン利用のため、公的個人認証サービスを用いて保証レベルBでの本人確認を行う。
- 利用者の本人確認(レベルB※)を行う業務
- 利用者の情報を管理する業務
- 認証前のトップ画面を表示
- コンテンツ管理_Webページ(静的コンテンツ)公開機能
- 利用者の当人認証を要する機能
- 申請・届出_申請・届出機能
- コンテンツ管理_Webページ(動的コンテンツ)公開機能 など
- 本人確認の保証レベルがレベルBの場合には、公的個人認証サービスと連携し、マイナンバーカードに搭載された電子証明書によって利用者の身元確認を行う手法がガイドラインで示されている。
- 一方、利用者の当人認証については、マイナンバーカードもしくは多要素認証による手法がガイドラインで示されており、本パターンではマイナンバーカードによる手法を示す。身元確認(ID作成)では、署名用証明書を用い、4情報(住所、氏名、生年月日、性別)を取得し、また、当人認証(システム利用)では、利用者証明証証明を用いることを想定している。利用者は、スマホ等の端末で電子証明書に設定したPIN/パスワードを入力し、マイナンバーカードの読み取りを行う。
- Amazon Cognitoのユーザプールの機能を使用し、公的個人認証サービスによって認証されたユーザに対するトークンを発行する。
- ユーザ情報を管理するためのWebAPIはAPI Gatewayにより構築される。
- API GatewayはAmazon CognitoをWebAPIの呼び出し可否の判断に使用するオーソライザーとして連携が可能である。
- Amazon Cognitoをオーソライザーとして設定することで、トークンの有効性確認の処理をAPI Gatewayに任せることができる。
- また、WAFによりインターネット経由で行われる様々な攻撃からAPIを保護する。
- Amazon DocumentDBに格納されたユーザ情報に対して、AWS Lambdaから新規作成や更新等の管理を行う。
- 本人確認の保証レベルがレベルBの場合には、公的個人認証サービスと連携し、マイナンバーカードに搭載された電子証明書によって利用者の身元確認を行う手法がガイドラインで示されている。
- 一方、利用者の当人認証については、マイナンバーカードもしくは多要素認証による手法がガイドラインで示されており、本パターンでは多要素認証による手法を示す。Amazon Cognitoにより、ワンタイムパスワードを用いた多要素認証を行う。
- Amazon Cognitoのユーザプールの機能を使用し、公的個人認証サービスによって認証されたユーザに対するトークンを発行する。
- ユーザ情報を管理するためのWebAPIはAPI Gatewayにより構築される。
- API GatewayはAmazon CognitoをWebAPIの呼び出し可否の判断に使用するオーソライザーとして連携が可能である。
- Amazon Cognitoをオーソライザーとして設定することで、トークンの有効性確認の処理をAPI Gatewayに任せることができる。
- また、WAFによりインターネット経由で行われる様々な攻撃からAPIを保護する。
- Amazon DocumentDBに格納されたユーザ情報に対して、AWS Lambdaから新規作成や更新等の管理を行う。
- 本人確認の保証レベルがレベルBの場合には、公的個人認証サービスと連携し、マイナンバーカードに搭載された電子証明書によって利用者の身元確認を行う手法がガイドラインで示されている。
- 一方、利用者の当人認証については、マイナンバーカードもしくは多要素認証による手法がガイドラインで示されており、本パターンでは多要素認証による手法を示す。ID管理のOSSにより、ワンタイムパスワードを用いた多要素認証を行う。
- OSSで実現するID管理では、ユーザ情報の保管先としてマネージドなデータベースを第一の選択肢として利用する。
- 利用するOSSがサポートするデータベースに準拠し、データベースを選択する。利用するOSSがPostgreSQLまたはMySQLをサポートする場合は、Amazon Auroraが利用できる。
- ID管理機能が発行したトークンによるアクセス制御を行い、他のWebAPIを提供する機能ブロックへアクセスする。
- トークンの検証は、Amazon API GatewayのLambda Authorizerの機能を用い、サーバレスで実現する方法が考えられる。
- 本人確認の保証レベルがレベルBの場合には、確認書類の郵送による身元確認と多要素認証による当人認証を行う手法がガイドラインで示されている。
- ID管理のOSSにより、ワンタイムパスワードを用いた多要素認証を行う。法人・個人事業主向け共通認証システムであるGビズIDでは、gBizIDプライムまたはgBizIDメンバーが保証レベルのレベルBに対応している。(※の2.4 保証レベルより)
- なお、GビズID発行について、個人事業主向けにはすでにオンライン発行可能となっている。また、法人代表者向けには令和5年度末にオンライン化が予定されている。
- Amazon Cognitoのユーザプールの機能を使用し、GビズIDとの連携(フェデレーション)を実行する。
- gBizIDとは、標準的な認証の仕様であるOpenID Connectのフローに従い、ユーザの認証を行う。
- ユーザ情報を管理するためのWebAPIはAPI Gatewayにより構築される。API GatewayはAmazon CognitoをWebAPIの呼び出し可否の判断に使用するオーソライザーとして連携が可能である。
- Amazon Cognitoをオーソライザーとして設定することで、トークンの有効性確認の処理をAPI Gatewayに任せることができる。
- また、WAFによりインターネット経由で行われる様々な攻撃からAPIを保護する。
- Amazon DocumentDBに格納されたユーザ情報に対して、AWS Lambdaから新規作成や更新等の管理を行う
- Amazon Cognitoが発行したトークンによるアクセス制御を行い、他のWebAPIを提供する機能ブロックへアクセスする。トークンの検証は、Amazon API GatewayのLambda Authorizerの機能を用い、サーバレスで実現する方法が考えられる。
- 行政システムのオンライン利用のため、公的個人認証サービスを用いて保証レベルCでの本人確認を行う。
- 利用者の本人確認(レベルC※)を行う業務
- 利用者の情報を管理する業務
- 認証前のトップ画面を表示
- コンテンツ管理_Webページ(静的コンテンツ)公開機能
- 利用者の当人認証を要する機能
- 申請・届出_申請・届出機能
- コンテンツ管理_Webページ(動的コンテンツ)公開機能 など
- 本人確認の保証レベルがレベルCの場合には、身元確認が不要であるが、アカウント作成時に入力されたメールアドレスや携帯電話番号の正当な所有者であることの確認を行う。 Amazon Cognitoでは、メールまたはSMSによるアカウント作成時の検証をサポートしている。
- また、当人認証に関しては、Amazon Cognitoが保管するIDとパスワードを用いて実現する。
- ユーザ情報を管理するためのWebAPIはAPI Gatewayにより構築される。
- API GatewayはAmazon CognitoをWebAPIの呼び出し可否の判断に使用するオーソライザーとして連携が可能である。
- Amazon Cognitoをオーソライザーとして設定することで、トークンの有効性確認の処理をAPI Gatewayに任せることができる。
- また、WAFによりインターネット経由で行われる様々な攻撃からAPIを保護する。
- Amazon DocumentDBに格納されたユーザ情報に対して、AWS Lambdaから新規作成や更新等の管理を行う。
- Amazon Cognitoが発行したトークンによるアクセス制御を行い、他のWebAPIを提供する機能ブロックへアクセスする。
- トークンの検証は、Amazon API GatewayのLambda Authorizerの機能を用い、サーバレスで実現する方法が考えられる。
- 本人確認の保証レベルがレベルCの場合には、身元確認が不要であるが、アカウント作成時に入力されたメールアドレスや携帯電話番号の正当な所有者であることの確認を行う。
- OSSは、認証に関する要件に応じて選択するものとする。例えば、OpenID ConnectのOPの機能を実現するミドルウェアや、シンプルなIDとパスワードによる認証を実現するライブラリなどから、要件に応じて選択する。
- また、ミドルウェアやライブラリの利用に関しての制約が一般的には少ないコンテナ(Amaon ECS) に加え、AWS Lambdaによるサーバレス構成も検討できる。
- OSSで実現するID管理では、ユーザ情報の保管先としてマネージドなデータベースを第一の選択肢として利用する。
- 利用するOSSがサポートするデータベースに準拠し、データベースを選択する。利用するOSSがPostgreSQLまたはMySQLをサポートする場合は、Amazon Auroraが利用できる。
- ID管理機能が発行したトークンによるアクセス制御を行い、他のWebAPIを提供する機能ブロックへアクセスする。
- トークンの検証は、Amazon API GatewayのLambda Authorizerの機能を用い、サーバレスで実現する方法が考えられる。
5-1-1-1. 利用者認証_本人確認機能（レベルA）
概要：
達成できる業務：
※「行政手続におけるオンラインによる本人確認の手法に関するガイドライン」に定義されている保証レベルを指す。また、本構成例における「ガイドライン」は「行政手続におけるオンラインによる本人確認の手法に関するガイドライン」を指す。
インタフェース例：
| インプット | 処理内容 | アウトプット |
|---|---|---|
| ・ユーザ情報の登録リクエスト | ・公的個人認証サービスによる身元確認を行い、ユーザ情報を登録 | ・なし |
| ・公的個人認証サービスによる当人認証の結果 | ・当人認証の結果が正当であることを確認する | ・認証済みであることを示すトークンを返却 |
| ・ユーザ情報の参照リクエエスト | ・登録済みのユーザ情報を取得する | ・ユーザ情報を返却 |
| ・ユーザ情報の更新データ | 更新データを受信し、登録済みのユーザ情報を更新する | ・なし |
| ・ユーザ情報の削除リクエスト | 削除リクエストを受信し、登録済みのユーザ情報を削除する | ・なし |
| ・本人確認機能が発行したトークン | トークンが正当なものであることを検証する | ・なし |
連携機能ブロック：
本人確認機能（レベルA）
ブロック実現例 （#サーバレスバックエンド）
ブロック実現例 説明
[1]
※ 利用システム向けの機能が公的認証サービスから直接提供されるわけではなく、認証・署名サービスが別途必要である。
認定事業者の既存サービスまたは独自に構築する選択肢がある。
公的個人認証サービスに関する技術情報(インタフェース仕様、連携のための手続きや制約事項等)は、別途確認する必要がある。
また、アプリケーションのトークン発行に関するAmazon Cognitoの構成はあくまで例であり、実現性を保証するものではない。認証。署名サービスとの接続仕様や利用システムの要件に応じて構成を検討する必要がある。
[2]
[3]
[4]
5-1-1-2. 利用者認証_本人確認機能（レベルB）
概要：
達成できる業務：
※「行政手続におけるオンラインによる本人確認の手法に関するガイドライン」に定義されている保証レベルを指す。また、本構成例における「ガイドライン」は「行政手続におけるオンラインによる本人確認の手法に関するガイドライン」を指す。
インタフェース例：
| インプット | 処理内容 | アウトプット |
|---|---|---|
| ・ユーザ情報の登録リクエスト | ・身元確認を行い、ユーザ情報を登録(身元確認は、個人の場合は公的個人認証サービス、法人の場合は書類郵送により行う) | ・なし |
| ・公的個人認証サービスによる当人認証の結果 | ・当人認証の結果が正当であることを確認する | ・認証済みであることを示すトークンを返却 |
| ・ユーザ情報の参照リクエエスト | ・登録済みのユーザ情報を取得する | ・ユーザ情報を返却 |
| ・ユーザ情報の更新データ | 更新データを受信し、登録済みのユーザ情報を更新する | ・なし |
| ・ユーザ情報の削除リクエスト | 削除リクエストを受信し、登録済みのユーザ情報を削除する | ・なし |
| ・本人確認機能が発行したトークン | トークンが正当なものであることを検証する | ・なし |
連携機能ブロック：
本人確認機能（レベルB）（パターン1 個人/身元確認:マイナンバーカード、当人認証:マイナンバーカード）
ブロック実現例 （#サーバレスバックエンド）
ブロック実現例 説明
[1]
※ 利用システム向けの機能が公的認証サービスから直接提供されるわけではなく、認証・署名サービスが別途必要である。
認定事業者の既存サービスまたは独自に構築する選択肢がある。
公的個人認証サービスに関する技術情報(インタフェース仕様、連携のための手続きや制約事項等)は、別途確認する必要がある。
また、アプリケーションのトークン発行に関するAmazon Cognitoの構成はあくまで例であり、実現性を保証するものではない。認証。署名サービスとの接続仕様や利用システムの要件に応じて構成を検討する必要がある。
[2]
[3]
[4]
本人確認機能（レベルB）（パターン2 個人/身元確認:マイナンバーカード、当人認証:多要素認証(Amazon Cognito利用)）
ブロック実現例 （#サーバレスバックエンド）
ブロック実現例 説明
[1]
※ 利用システム向けの機能が公的認証サービスから直接提供されるわけではなく、認証・署名サービスが別途必要である。
認定事業者の既存サービスまたは独自に構築する選択肢がある。
公的個人認証サービスに関する技術情報(インタフェース仕様、連携のための手続きや制約事項等)は、別途確認する必要がある。
また、アプリケーションのトークン発行に関するAmazon Cognitoの構成はあくまで例であり、実現性を保証するものではない。認証。署名サービスとの接続仕様や利用システムの要件に応じて構成を検討する必要がある。
[2]
[3]
[4]
本人確認機能（レベルB）（パターン3 個人/身元確認:マイナンバーカード、当人認証:多要素認証(OSS利用)）
ブロック実現例 （#コンテナバックエンド）
ブロック実現例 説明
[1]
※ 利用システム向けの機能が公的認証サービスから直接提供されるわけではなく、認証・署名サービスが別途必要である。
認定事業者の既存サービスまたは独自に構築する選択肢がある。
公的個人認証サービスに関する技術情報(インタフェース仕様、連携のための手続きや制約事項等)は、別途確認する必要がある。
[2]
[3]
本人確認機能（レベルB）（パターン4 法人/身元確認:GビズID、当人認証:多要素認証(GビズID)）
ブロック実現例 （#サーバレスバックエンド）
ブロック実現例 説明
[1]
※ gBizID システム連携ガイド（行政サービス向け）: https://gbiz-id.go.jp/top/system_guide/system_guide.htmlOpens in new tab
[2]
[3]
[4]
[5]
※ Amazon Cognitoでは、リクエストレートクォータとして、単位時間あたりのAPI呼び出しに上限が設定されている。リクエストレートクォータを上回る負荷が想定される場合には、Amazon Cognitoではなく、Amazon ECSを利用してコンテナ上で認証認可サーバを独自に構築する方法や、認証認可サーバの機能を提供する外部サービスの利用などの代替案を検討する必要がある。
5-1-1-3. 利用者認証_本人確認機能（レベルC）
概要：
達成できる業務：
※「行政手続におけるオンラインによる本人確認の手法に関するガイドライン」に定義されている保証レベルを指す。また、本構成例における「ガイドライン」は「行政手続におけるオンラインによる本人確認の手法に関するガイドライン」を指す。
インタフェース例：
| インプット | 処理内容 | アウトプット |
|---|---|---|
| ・ユーザ情報の登録リクエスト | ・登録リクエストに含まれるユーザ情報を仮登録 登録リクエストに含まれるメールアドレスまたは携帯電話番号に確認コードを送信 | ・なし |
| ・ユーザ情報の登録リクエスト(確認コード) | ・確認コードが正しい場合、ユーザのステータスをを本人確認済みに更新 | ・なし |
| ・利用者が設定したIDとパスワード | ・登録済みのIDとパスワードと一致するかを確認する | ・認証済みであることを示すトークンを返却 |
| ・ユーザ情報の参照リクエエスト | ・登録済みのユーザ情報を取得する | ・ユーザ情報を返却 |
| ・ユーザ情報の更新データ | 更新データを受信し、登録済みのユーザ情報を更新する | ・なし |
| ・ユーザ情報の削除リクエスト | 削除リクエストを受信し、登録済みのユーザ情報を削除する | ・なし |
| ・本人確認機能が発行したトークン | トークンが正当なものであることを検証する | ・なし |
連携機能ブロック：
本人確認機能（レベルC）(パターン1 個人または法人/身元確認:なし、当人認証:単要素認証/Amazon Cognito利用)
ブロック実現例 （#サーバレスバックエンド）
ブロック実現例 説明
[1]
[2]
[3]
[4]
※ Amazon Cognitoでは、リクエストレートクォータとして、単位時間あたりのAPI呼び出しに上限が設定されている。リクエストレートクォータを上回る負荷が想定される場合には、Amazon Cognitoではなく、Amazon ECSを利用してコンテナ上で認証認可サーバを独自に構築する方法や、認証認可サーバの機能を提供する外部サービスの利用などの代替案を検討する必要がある。
本人確認機能（レベルC）(パターン2 個人/身元確認:なし、当人認証:単要素認証/OSS利用)
ブロック実現例 （#コンテナバックエンド）
ブロック実現例 説明
[1]
[2]
[3]
5-1-2. 申請・届出
- 所管する行政手続について利用システムを通じて申請・届出の受付、修正、取り下げを行う。
- 申請者からの届出・申請内容の受理業務
- 届出・申請内容の修正や取り下げも受け付ける
- 利用者の認証
- 利用者認証_ユーザ認証機能（国民向け）
- 利用者認証_ユーザ認証機能（企業ユーザ向け）
- 利用者認証_ユーザ認証機能（職員向け）
- 届出・申請内容に対する審査・承認
- 申請・届出_電子決裁機能
- 申請・届出_ステータス管理機能
- SPA（Single Page Application）における静的ファイル（HTML、JavaScript、CSS）をCloudFront及びS3で配信する。
- ファイルは高耐久なオブジェクトストレージであるS3に保管する。CloudFrontはCDNとしての機能を提供し、大量のリクエストにも低レイテンシーでの応答を実現する。
- またWAF(※)によりインターネット経由で行われる様々な攻撃からフロントエンド配信機能を保護する。
※WAFのルールグループについては非機能ブロック「セキュリティ_通信を介した攻撃への保護」を参照すること。 - ユーザーは他の機能ブロックにおいてユーザ認証を行い、認証トークンを取得する。
- 申請・届出の入力に使用するWebアプリケーションは、フロントエンド、バックエンド分離の構成とし、バックエンド側はコンテナ上で動作させる。
- ELBにWAFを関連づけることにより、インターネット経由で行われる様々な攻撃からWebアプリケーションを保護する。
- ユーザーは他の機能ブロックにおいてユーザ認証を行い、認証トークンを取得する。
- 取得した認証トークンは、Webアプリケーションによって検証される。
- 認可されたリクエストは、バックエンドアプリケーションによって入力データ、および提出ファイルの形式チェックを行う。
- 内容に問題がない場合はデータベースに保存される。
- データベースはマネージドなRDBであるAuroraを利用し、運用コストを削減する。
- 他の機能ブロックは申請・届出内容保管データベースを参照することができる。
- SPA（Single Page Application）における静的ファイル（HTML、JavaScript、CSS）をCloudFront及びS3で配信する。
- ファイルは高耐久なオブジェクトストレージであるS3に保管する。CloudFrontはCDNとしての機能を提供し、大量のリクエストにも低レイテンシーでの応答を実現する。またWAF(※)によりインターネット経由で行われる様々な攻撃からフロントエンド配信機能を保護する。
※WAFのルールグループについては非機能ブロック「セキュリティ_通信を介した攻撃への保護」を参照すること。 - ユーザーは他の機能ブロックにおいてユーザ認証を行い、認証トークンを取得する。
- 申請・届出の入力に使用するWebアプリケーションは、フロントエンド、バックエンド分離の構成とし、バックエンド側はコンテナ上で動作させる。
- ELBにWAFを関連づけることにより、インターネット経由で行われる様々な攻撃からWebアプリケーションを保護する。
- ユーザーは他の機能ブロックにおいてユーザ認証を行い、認証トークンを取得する。
- 取得した認証トークンは、Webアプリケーションによって検証される。
- 認可されたリクエストは、バックエンドアプリケーションによって入力データ、および提出ファイルの形式チェックを行う。
- 内容に問題がない場合はS3に保存される。
- 他の機能ブロックは申請・届出内容保管ストレージ内のファイルを参照することができる。
- SPA（Single Page Application）における静的ファイル（HTML、JavaScript、CSS）をCloudFront及びS3で配信する。
- ファイルは高耐久なオブジェクトストレージであるS3に保管する。CloudFrontはCDNとしての機能を提供し、大量のリクエストにも低レイテンシーでの応答を実現する。またWAF(※)によりインターネット経由で行われる様々な攻撃からフロントエンド配信機能を保護する。
※WAFのルールグループについては非機能ブロック「セキュリティ_通信を介した攻撃への保護」を参照すること。 - ユーザーは他の機能ブロックにおいてユーザ認証を行い、認証トークンを取得する。
- 申請・届出の入力に使用するWebアプリケーションは、フロントエンド、バックエンド分離の構成とし、バックエンド側はコンテナ上で動作させる。
- ELBにWAFを関連づけることにより、インターネット経由で行われる様々な攻撃からWebアプリケーションを保護する。
- ユーザーは他の機能ブロックにおいてユーザ認証を行い、認証トークンを取得する。
- 取得した認証トークンは、Webアプリケーションによって検証される。
- コンテナ上のバックエンドアプリケーションは、S3へデータをアップロードするための時間制限付き署名付きURLを発行し、クライアントへ渡す。
- 入力データは署名付きURLからS3へファイルとしてアップロードされる。S3へのアップロードイベントをトリガーとしてファイル検証関数が実行され、入力データを検証する。
- マルウェア対策として、Amazon GuardDuty Malware Protection for Amazon S3の導入も検討すること。
- 入力データの検証結果は利用者通知_メッセージ通知機能を介してユーザーへ通知される。
- SPA（Single Page Application）における静的ファイル（HTML、JavaScript、CSS）をCloudFront及びS3で配信する。
- ファイルは高耐久なオブジェクトストレージであるS3に保管する。CloudFrontはCDNとしての機能を提供し、大量のリクエストにも低レイテンシーでの応答を実現する。またWAF(※)によりインターネット経由で行われる様々な攻撃からフロントエンド配信機能を保護する。
※WAFのルールグループについては非機能ブロック「セキュリティ_通信を介した攻撃への保護」を参照すること。 - ユーザーは他の機能ブロックにおいてユーザ認証を行い、認証トークンを取得する。
- 申請・届出の入力に使用するWebアプリケーションは、フロントエンド、バックエンド分離の構成とし、バックエンド側はコンテナ上で動作させる。
- ELBにWAFを関連づけることにより、インターネット経由で行われる様々な攻撃からWebアプリケーションを保護する。
- ユーザーは他の機能ブロックにおいてユーザ認証を行い、認証トークンを取得する。
- 取得した認証トークンは、Webアプリケーションによって検証される。
- 認可されたリクエストは、バックエンドアプリケーションにて処理される。
- 処理結果はデータベースに保存される。データベースはマネージドなDocumentDBを利用し、運用コストを削減する。
- 他の機能ブロックは申請・届出内容保管データベースを参照することができる。
- 申請・届出時に添付する本人確認者や各種証明書等の資料の管理を行う。
- 届出・申請時に添付された本人確認者や各種証明書等の管理
- UIを提供する機能
- コンテンツ管理_Webページ（静的コンテンツ）公開機能
- 申請・届出_申請・届出機能
- 認証機能
- ユーザ認証機能（国民向け）
- ユーザ認証機能（企業向け）
- ユーザ認証機能（職員向け）
- データ利用機能
- 申請・届出_ステータス管理機能
- 申請・届出_電子決裁機能
- 本機能は、別機能における処理の中で添付資料のアップロードが必要になった場合に利用される想定。
- ユーザーは他の機能ブロックにおいてユーザ認証を行い、認証トークンを取得する。
- 添付資料アップロード用のWebアプリケーションはバックエンドのコンテナアプリケーションで動作させる。
- ELBにWAF(※)を関連づけることにより、インターネット経由で行われる様々な攻撃からWebアプリケーションを保護する。
※WAFのルールグループについては非機能ブロック「セキュリティ_通信を介した攻撃への保護」を参照すること。 - Webアプアプリケーションのリクエストの認可は認証系の機能ブロックにより発行されるトークンを検証することによって行われる。
- リクエストヘッダーに含まれるトークンの有効性を検証する。
- トークンが有効な場合のみ、リクエストは受理される。
- 認可されたリクエストは、添付資料処理関数にてS3へ保存される。
- この関数では要件に応じて、添付資料の整形や検証も行う。
- 他の機能ブロックは添付資料保管ストレージ内のファイルを参照することができる。
- 本機能は、別機能における処理の中で添付資料のアップロードが必要になった場合に利用される想定。
- ユーザーは他の機能ブロックにおいてユーザ認証を行い、認証トークンを取得する。
- 添付資料アップロード用のWebアプリケーションはバックエンドのコンテナアプリケーションで動作させる。
- ELBにWAF(※)を関連づけることにより、インターネット経由で行われる様々な攻撃からWebアプリケーションを保護する。
※WAFのルールグループについては非機能ブロック「セキュリティ_通信を介した攻撃への保護」を参照すること。 - Webアプアプリケーションのリクエストの認可は認証系の機能ブロックにより発行されるトークンを検証することによって行われる。
- リクエストヘッダーに含まれるトークンの有効性を検証する。
- トークンが有効な場合のみ、リクエストは受理される。
- コンテナアプリケーションはS3へデータをアップロードするための時間制限付き署名付きURLを発行し、クライアントへ渡す。
- クライアントは署名付きURLでS3へ添付資料をアップロードする。
- Amazon EventBridgeを用い、アップロードされた添付資料に関する通知を連携機能に送信する。
- Amazon EventBridgeにより、1つの添付資料に関する通知を複数の連携機能に送信(ファンアウト)することが可能である。
- また、Amazon EventBridgeでは、ファイル名等を用いて、通知送信の有無や通知送信先の振り分けが可能である。
- 他の機能ブロックは届出・申請内容保管ストレージ内のファイルを参照することができる。
- 利用者や職員による申請・届出を行った案件のステータス照会を行う。
- 申請者による申請状況の照会。
- 職員による申請状況の確認業務。
- 利用者の認証
- 利用者認証_ユーザ認証機能（国民向け）
- 利用者認証_ユーザ認証機能（企業ユーザ向け）
- 利用者認証_ユーザ認証機能（職員向け）
- ステータス情報の取得先
- 申請・届出_申請・届出機能
- 申請・届出_電子決裁機能
- SPA（Single Page Application）における静的ファイル（HTML、JavaScript、CSS）をCloudFront及びS3で配信する。
- ファイルは高耐久なオブジェクトストレージであるS3に保管する。CloudFrontはCDNとしての機能を提供し、大量のリクエストにも低レイテンシーでの応答を実現する。
- またWAF(※)によりインターネット経由で行われる様々な攻撃からフロントエンド配信機能を保護する。
※WAFのルールグループについては非機能ブロック「セキュリティ_通信を介した攻撃への保護」を参照すること。 - ユーザーは他の機能ブロックにおいてユーザ認証を行い、認証トークンを取得する。
- ステータスはREST APIで取得される。
- REST APIはAPI Gateway及びLambdaにより構築される。
- またWAFによりインターネット経由で行われる様々な攻撃からAPIを保護する。
- APIリクエストの認可は認証系の機能ブロックにより発行されるトークンを検証することによって行われる。
- API GatewayはLambda Authorizer機能により認証トークン検証関数を起動し、APIリクエストヘッダーに含まれるトークンの有効性を検証する。
- トークンが有効な場合のみ、APIリクエストは受理される。
- ステータスはステータス取得関数にて他機能のデータベースやストレージから取得される。
申請・届出_ステータス管理機能
- SPA（Single Page Application）における静的ファイル（HTML、JavaScript、CSS）をCloudFront及びS3で配信する。
- ファイルは高耐久なオブジェクトストレージであるS3に保管する。CloudFrontはCDNとしての機能を提供し、大量のリクエストにも低レイテンシーでの応答を実現する。
- またWAF(※)によりインターネット経由で行われる様々な攻撃からフロントエンド配信機能を保護する。
※WAFのルールグループについては非機能ブロック「セキュリティ_通信を介した攻撃への保護」を参照すること。 - ユーザーは他の機能ブロックにおいてユーザ認証を行い、認証トークンを取得する。
- ステータス取得のWebアプリケーションはバックエンドのコンテナアプリケーションで動作させる。
- ELBにWAFを関連づけることにより、インターネット経由で行われる様々な攻撃からWebアプリケーションを保護する。
- Webアプアプリケーションのリクエストの認可は認証系の機能ブロックにより発行されるトークンを検証することによって行われる。
- リクエストヘッダーに含まれるトークンの有効性を検証する。
- トークンが有効な場合のみ、リクエストは受理される。
- ステータスは、コンテナアプリケーションにて他機能のデータベースやストレージから取得される。
- 利用者が申請・届出を行った案件に関して行政機関から電子公文書交付を行う。
- 届出・申請の結果を含む公文書を、申請者に対して交付する業務。
- 申請者の認証
- 利用者認証_ユーザ認証機能（国民向け）
- 利用者認証_ユーザ認証機能（企業ユーザ向け）
- 公文書の作成
- 書類出力_法定帳票作成機能（外部）
- 書類出力_法定帳票作成機能（内部）
- 公文書を表示するWebサイトの配信
- コンテンツ管理_Webページ（静的コンテンツ）公開機能
- 本機能は、別機能における処理の中で公文書のダウンロードが必要になった場合に利用される想定である。
- ユーザーは他の機能ブロックにおいてユーザ認証を行い、認証トークンを取得する。
- 公文書ダウンロード用のWebアプリケーションはバックエンドのコンテナアプリケーションで動作させる。
- ELBにWAF(※)を関連づけることにより、インターネット経由で行われる様々な攻撃からWebアプリケーションを保護する。
※WAFのルールグループについては非機能ブロック「セキュリティ_通信を介した攻撃への保護」を参照すること。 - Webアプリケーションのリクエストの認可は認証系の機能ブロックにより発行されるトークンを検証することによって行われる。
- リクエストヘッダーに含まれるトークンの有効性を検証する。
- トークンが有効な場合のみ、リクエストは受理される。
- リクエストが認可された場合は、コンテナアプリケーションがS3から公文書を取得する。
- 他の機能ブロックが、公文書保管ストレージに公文書をアップロードする。
- 本機能は、別機能における処理の中で公文書のダウンロードが必要になった場合に利用される想定である。
- ユーザーは他の機能ブロックにおいてユーザ認証を行い、認証トークンを取得する。
- 公文書ダウンロード用のWebアプリケーションはバックエンドのコンテナアプリケーションで動作させる。
- ELBにWAF(※)を関連づけることにより、インターネット経由で行われる様々な攻撃からWebアプリケーションを保護する。
※WAFのルールグループについては非機能ブロック「セキュリティ_通信を介した攻撃への保護」を参照すること。 - Webアプリケーションのリクエストの認可は認証系の機能ブロックにより発行されるトークンを検証することによって行われる。
- リクエストヘッダーに含まれるトークンの有効性を検証する。
- トークンが有効な場合のみ、リクエストは受理される。
- コンテナアプリケーションはS3からデータをダウンロードするための時間制限付きの署名付きURLを発行し、クライアントへ渡す。
- クライアントは署名付きURLでS3から公文書をダウンロードする。
- 他の機能ブロックが、公文書保管ストレージに公文書をアップロードする。
- 行政機関から発出する電子公文書のインターネット公開を行う。
- 届出・申請の結果を一般公開する業務。
- 公文書の作成
- 書類出力_法定帳票作成機能（外部）
- 書類出力_法定帳票作成機能（内部）
- 公文書を表示するWebサイトの配信
- コンテンツ管理_Webページ（静的コンテンツ）公開機能
- 公文書をファイル（PDF等）として、CloudFront及びS3で配信し、一般公開を行う。
- ファイルは高耐久なオブジェクトストレージであるS3に保管する。CloudFrontはCDNとしての機能を提供し、大量のリクエストにも低レイテンシーでの応答を実現する。
- またWAF(※)によりインターネット経由で行われる様々な攻撃からフロントエンド配信機能を保護する。
※WAFのルールグループについては非機能ブロック「セキュリティ_通信を介した攻撃への保護」を参照すること。 - 公文書のファイルは、静的コンテンツの一部として公開される想定であり、コンテンツ管理_Webページ（静的コンテンツ）公開機能が提供するWebページに、公文書のファイルのダウンロード用URLが掲載される。
- 連携機能が作成したファイル（PDF等）を公文書配信ストレージにアップロードする。
- 補足：時刻指定での公文書公開を行う要件がある場合は、Webコンテンツ管理（CMS）機能の利用が推奨される。
- 申請時の手続き費用、税金などの国民から国への納付に係る金銭処理を行う。
- 申請に係る手数料などの納付を受け付ける業務
- 実際の金銭処理を担う外部システムと連携し、納付の状況を管理する
- 利用者の認証
- 利用者認証_ユーザ認証機能（国民向け）
- 利用者認証_ユーザ認証機能（企業ユーザ向け）
- 手数料等の納付を必要とする申請を受け付ける機能
- 申請・届出_申請・届出機能
- 申請・届出機能等の他の機能ブロックにおいて、手数料の納付が必要になった場合、本機能へのリクエストが送信される。
- Webアプリケーションは、フロントエンド、バックエンド分離の構成とし、バックエンド側はコンテナ上で動作させる。
- ELBにWAF(※)を関連づけることにより、インターネット経由で行われる様々な攻撃からWebアプリケーションを保護する。
※WAFのルールグループについては非機能ブロック「セキュリティ_通信を介した攻撃への保護」を参照すること。 - 手数料等の納付は、歳入金電子納付システム（REPS）と連携して行われる。REPSとの間で手数料の納付に関する情報を連携する。連携した情報をもとに、手数料納付ステータスを更新する。
（注）REPSに関する技術情報（インタフェース仕様、連携のための手続きや制約事項等）は、別途確認する必要がある。 - 手数料の納付ステータスはデータベースに保存し管理を行う。データベースはマネージドなRDBであるAmazon Auroraを利用し、運用コストを削減する。
- 申請後の補助金交付、還付金などの行政機関から国民への公金交付の金銭処理を行う。
- 補助金や還付金などの交付を実施する業務。
- 実際の金銭処理を担う外部システムと連携し、交付の状況を管理。
- 利用者の認証
- 利用者認証_ユーザ認証機能（国民向け）
- 利用者認証_ユーザ認証機能（企業ユーザ向け）
- 補助金等の交付に対する申請を受け付ける機能
- 申請・届出_申請・届出機能
- 補助金等の交付に関する通知を行う機能
- 利用者通知_メッセージ通知機能
- 申請・届出機能等の他の機能ブロックにおいて、補助金の交付が必要になった場合、本機能へのリクエストが送信される。
- Webアプリケーションは、フロントエンド、バックエンド分離の構成とし、バックエンド側はコンテナ上で動作させる。
- ELBにWAF(※)を関連づけることにより、インターネット経由で行われる様々な攻撃からWebアプリケーションを保護する。
※WAFのルールグループについては非機能ブロック「セキュリティ_通信を介した攻撃への保護」を参照すること。 - 補助金等の交付は、外部システムと連携して行われる。外部システムとの間で補助金の交付に関する情報を連携する。
- 連携した情報をもとに、補助金交付ステータスを更新する。
- (注)外部システムに関する技術情報(インタフェース仕様、連携のための手続きや制約事項等)は、別途確認する必要がある。
- 補助金の交付ステータスはデータベースに保存し管理を行う。
- データベースはマネージドなRDBであるAmazon Auroraを利用し、運用コストを削減する。
- 申請から承認までの決裁ワークフロー、および申請案件管理（登録、更新、参照）を行う。
- 届出・申請や審査・承認に関する様々な処理をワークフロー化して実施。
- 決裁ワークフローを開始
- 申請・届出_申請・届出機能
- 審査・承認_審査・承認機能
- 決裁ワークフロー内の個別処理
- ワークフローに必要な機能ブロックを選択
- 審査・承認_審査・承認機能等の他の機能ブロックにおいて、決裁ワークフローによる処理が必要になった場合、本機能へのリクエストが送信される。
- 決裁に関連する一連の処理を、AWS Step Functionsを用いてワークフローとして作成する。
- AWS Step Functionsでは、複数の機能ブロックを組み合わせたワークフローの作成が可能である。
- ワークフローの一例として、審査・承認の結果を帳票として作成及び交付し、利用者に通知する一連の処理を示している。AWS Step Functionsでは、各機能ブロックで使用するAWS Lambda等を指定した順番で呼び出すワークフローの作成が可能である。
- AWS Step Functionsでは、GUI上の操作によってワークフローを作成することが可能である。
- ワークフローの構成要素して、条件分岐や並列処理、ループ処理などの、ワークフローの制御で必要になる処理があらかじめ用意されている。そのため、ワークフローの制御の部分をAWS Step Functionsの機能に任せることができる。
- また、AWS Step Functionsでは、タスクトークンの機能を用いて、ワークフローの実行を一時停止することができる。この機能を用いて、例えば、承認者の承認行為をワークフローの一部として構成することも可能である。
5-1-2-1. 申請・届出_申請・届出機能
概要：
達成できる業務：
インタフェース例：
| インプット | 処理内容 | アウトプット |
|---|---|---|
| ・新規登録用の申請・届出データ（1件/一括） | ・受信した申請・届出内容を自動的にチェックし、データとして登録する | ・なし |
| ・届出・申請の参照リクエスト（検索条件付き） | ・登録済みの届出・申請データを取得 ・検索条件（例. 届出・申請の承認ステータス）に応じて、申請・届出データを絞り込み | ・申請・届出内容を返却 |
| ・申請・届出に対する補正データ | ・補正データを受信し、登録済みのデータを更新する | ・なし |
| ・申請・届出の取り下げリクエスト | 取り下げリクエストを受信し、登録済みのデータを削除する | ・なし |
連携機能ブロック：
申請・届出_申請・届出機能（パターン1 Aurora保管）
ブロック実現例 （#コンテナバックエンド #サーバレスフロントエンド）
ブロック実現例 説明
[1]
[2]
[3]
[4]
[5]
[6]
申請・届出_申請・届出機能（パターン2 S3保管）
ブロック実現例 （#コンテナバックエンド #サーバレスフロントエンド）
ブロック実現例 説明
[1]
[2]
[3]
[4]
[5]
[6]
申請・届出_申請・届出機能（パターン3 S3保管+署名付きURL利用）
ブロック実現例 （#コンテナバックエンド #サーバレスフロントエンド #ストレージ直接アクセス）
ブロック実現例 説明
[1]
[2]
[3]
[4]
[5]
[6]
[7]
申請・届出_申請・届出機能（パターン4 DocumentDB利用）
ブロック実現例 （#コンテナバックエンド #サーバレスフロントエンド）
ブロック実現例 説明
[1]
[2]
[3]
[4]
[5]
[6]
5-1-2-2. 申請・届出_添付資料管理機能
概要：
達成できる業務：
インタフェース例：
| インプット | 処理内容 | アウトプット |
|---|---|---|
| ・添付資料 | ・アップロードされたファイルをデータとして登録する。 ・要件に応じて、添付資料の整形や検証を行う。 | ・なし |
連携機能ブロック：
申請・届出_添付資料管理機能（パターン1 ）
ブロック実現例 （#コンテナバックエンド）
ブロック実現例 説明
[1]
[2]
[3]
[4]
[5]
[6]
申請・届出_添付資料管理機能（パターン2 署名付きURL利用）
ブロック実現例 （#コンテナバックエンド #ストレージ直接アクセス サーバレスイベント処理）
ブロック実現例 説明
[1]
[2]
[3]
[4]
[5]
[6]
[7]
[8]
5-1-2-3. 申請・届出_ステータス管理機能
概要：
達成できる業務：
インタフェース例：
| インプット | 処理内容 | アウトプット |
|---|---|---|
| ・届出・申請の参照リクエスト（申請者向け） | ・登録済みの届出・申請データを取得 ・検索条件（例. 届出・申請の承認ステータス）に応じて、届出・申請データを絞り込み ※自身が登録したデータのみ参照可 | 届出・申請のステータスを返却 |
| ・届出・申請の参照リクエスト（職員向け） | ・登録済みの届出・申請データを取得 ・検索条件（例. 届出・申請の承認ステータス）に応じて、届出・申請データを絞り込み ※管理用途として、申請者単位の制限なくデータを参照可 | 届出・申請のステータスを返却 |
連携機能ブロック：
申請・届出_ステータス管理機能
ブロック実現例 （#サーバレスバックエンド #サーバレスフロントエンド）
ブロック実現例 説明
[1]
[2]
[3]
[4]
[5]
ブロック実現例 （#コンテナバックエンド #サーバレスフロントエンド）
ブロック実現例 説明
[1]
[2]
[3]
[4]
[5]
5-1-2-4. 申請・届出_公文書ダウンロード機能
概要：
達成できる業務：
インタフェース例：
| インプット | 処理内容 | アウトプット |
|---|---|---|
| [呼び出し元: 利用者] ・公文書の参照リクエスト | ・ストレージから公文書（PDF等）を取得し返却。 ・ストレージから公文書（PDF等）を直接ダウンロードするためのリンクを生成し返却。 | 公文書 |
| [呼び出し元: 連携機能] ・公文書（新規登録） | ・公文書（PDF等）をストレージに保存 | なし |
| [呼び出し元: 連携機能] ・公文書（更新） | ストレージに保存済みの公文書（PDF等）を更新 | なし |
| [呼び出し元: 連携機能] ・公文書の削除リクエスト | 公文書（PDF等）をストレージから削除 | なし |
連携機能ブロック：
申請・届出_公文書ダウンロード機能（パターン1 Lambda経由でのダウンロード）
ブロック実現例 （#コンテナバックエンド）
ブロック実現例 説明
[1]
[2]
[3]
[4]
[5]
[6]
申請・届出_公文書ダウンロード機能（パターン2 署名付きURLを用いたS3からのダウンロード）
ブロック実現例 （#コンテナバックエンド #ストレージ直接アクセス）
ブロック実現例 説明
[1]
[2]
[3]
[4]
[5]
[6]
[7]
5-1-2-5. 申請・届出_公文書公開機能
概要：
達成できる業務：
インタフェース例：
| インプット | 処理内容 | アウトプット |
|---|---|---|
| [呼び出し元: 利用者] ・公文書の参照リクエスト | ・ストレージから公文書（PDF等）を取得し返却。 | ・公文書 |
| [呼び出し元: 連携機能] ・公文書（新規登録） ・公開予定時刻 ※時刻指定の公開を行う場合 | ・公文書（PDF等）をストレージに保存 ・公文書（PDF等）に対して公開予定時刻を設定 ※時刻指定の公開を行う場合 | ・なし |
| [呼び出し元: 連携機能] ・公文書（更新） | ・ストレージに保存済みの公文書（PDF等）を更新 | ・なし |
| [呼び出し元: 連携機能] ・公文書の削除リクエスト | ・公文書（PDF等）をストレージから削除 | ・なし |
連携機能ブロック：
申請・届出_公文書公開機能
ブロック実現例 （#サーバレスフロントエンド）
ブロック実現例 説明
[1]
[2]
[3]
[補足]
5-1-2-6. 申請・届出_手数料等電子納付機能
概要：
達成できる業務：
インタフェース例：
| インプット | 処理内容 | アウトプット |
|---|---|---|
| ・新規登録用の納付データ（1件/一括） | ・納付データを登録する ・納付データを外部システムに連携 | ・なし |
| ・納付ステータスの参照リクエスト（検索条件付き） | ・登録済みの納付データを取得 ・検索条件（例. 支払い有無のステータス）に応じて、納付データを絞り込み | ・納付データ |
| ・納付の取り下げリクエスト | ・取り下げリクエストを受信し、登録済みの納付データを削除する。 | ・なし |
連携機能ブロック：
※実際の金銭処理を担う外部システムと納付の状況を連携するために、追加のインタフェースが必要になる可能性がある。例えば、外部システムが本機能ブロックに対して、納付状況に関するデータを送信するケースが該当する。
外部システムの仕様に合わせて、インタフェースの必要性を検討する必要がある。
申請・届出_手数料等電子納付機能
ブロック実現例 （#コンテナバックエンド）
ブロック実現例 説明
[1]
[2]
[3]
[4]
5-1-2-7. 申請・届出_補助金等電子交付機能
概要：
達成できる業務：
インタフェース例：
| インプット | 処理内容 | アウトプット |
|---|---|---|
| ・新規登録用の交付データ(1件/一括) | ・交付データを登録する 交付データを外部システムに連携 | ・なし |
| ・交付ステータスの参照リクエスト(検索条件付き) | ・登録済みの交付データを取得 検索条件(例. 振込のステータス)に応じて、交付データを絞り込み | ・交付データ |
| ・交付の取り下げリクエスト | ・取り下げリクエストを受信し、登録済みの交付データを削除する | ・なし |
連携機能ブロック：
※ 実際の金銭処理を担う外部システムと交付の状況を連携するために、追加のインタフェースが必要になる可能性がある。例えば、外部システムが本機能ブロックに対して、交付状況に関するデータを送信するケースが該当する。外部システムの仕様に合わせて、インタフェースの必要性を検討する必要がある。
申請・届出_補助金等電子交付機能
ブロック実現例 （#コンテナバックエンド）
ブロック実現例 説明
[1]
[2]
[3]
[4]
5-1-2-8. 申請・届出_電子決裁機能
概要：
達成できる業務：
インタフェース例：
| インプット | 処理内容 | アウトプット |
|---|---|---|
| ・決裁ワークフローの処理に必要なデータ（例. 審査・承認結果） | ・定義した決裁ワークフローにしたがって、各機能を実行 | ・決裁ワークフロー内の各機能のアウトプット（例. 利用者への通知メール） |
連携機能ブロック：
申請・届出_電子決裁機能
ブロック実現例
ブロック実現例 説明
[1]
[2]
[3]
5-1-3. 審査・承認
- 行政業務における審査の受付やその承認処理を行う。
- 統計調査やアンケートの回答内容を審査する。
- 審査対象データ・審査結果保管機能
- 申請・届出_申請・届出機能
- 申請・届出_電子決裁機能
- 審査結果を参照し処理する機能
- 申請・届出_公文書ダウンロード機能
- 申請・届出_公文書公開機能
- 認証機能
- 利用者認証_ユーザ認証機能（国民向け）
- 利用者認証_ユーザ認証機能（企業ユーザ向け）
- 利用者認証_ユーザ認証機能（職員向け）
- 本パターンは、審査対象に対して承認者が審査結果を決定することを想定している。承認者は、本パターンによって構成されるWebアプリケーションを利用して、審査を行う。
- 審査データの参照及び、結果入力に使用するWebアプリケーションは、コンテナを利用し、フロントエンドとバックエンドそれぞれを別個のECSタスクとして動作させる。
- 承認者がインターネット経由でアクセスすることを前提とした場合は、フロントエンドはCDN+オブジェクトストレージで配信する構成へ置き換えることも可能である。
- ELBにWAF(※)を関連づけることにより、ネットワーク経由で行われる様々な攻撃からWebアプリケーションを保護する。
- ユーザーは他の機能ブロックにおいてユーザ認証を行い、認証トークンを取得する。
- 取得した認証トークンは、Webアプリケーションによって検証される。
- 審査結果は審査データ保管データベース・ストレージに保存される。
- 審査結果は他の機能により参照される。
- 本パターンは、審査対象に対してシステムが審査結果を自動的に決定することを想定している。
- 審査対象データがストレージに追加されたことをトリガーにして、審査処理が自動起動する。
- Amazon EventBridgeを用い、ストレージに追加された審査対象データに関する通知を審査処理関数に送信する。
- AWS Lambdaにより、審査対象に対する審査を行う。
- システムによるルールベースの判断(例. 入力された値が基準の範囲内か、入力された文字列が基準文字列と一致するか等)により審査が可能な場合を想定している。
- 審査に必要となる審査基準データは、データベースから取得する。
- なお、審査の処理が複数ステップにわたる場合には、申請・届出_電子決裁機能と組み合わせ、AWS StepFunctionsによるワークフローを構成しても良い。
- 審査に必要となる審査基準データを保管する。
- 審査基準に変更があった場合には、審査基準データを更新することを想定している。
- 本パターンでは、審査基準データ及び審査データの保管先データベースとしてAmazon Auroraを利用しているが、Amazon DocumentDBを利用するバリエーションも有り得る。
- 審査結果は他の機能により参照される。
- 本パターンは、審査対象に対してシステムが審査結果を自動的に決定することを想定している。
- 審査対象データがデータベースに追加されたことをトリガーにして、審査処理が自動起動する。
- Amazon DocumentDBの変更ストリームを用い、データベースに追加された審査対象データを審査処理関数にストリームとして送信する。
- AWS Lambdaにより、審査対象に対する審査を行う。
- システムによるルールベースの判断(例. 入力された値が基準の範囲内か、入力された文字列が基準文字列と一致するか等)により審査が可能な場合を想定している。
- 審査に必要となる審査基準データは、データベースから取得する。
- なお、審査の処理が複数ステップにわたる場合には、申請・届出_電子決裁機能と組み合わせ、AWS StepFunctionsによるワークフローを構成しても良い。
- 審査に必要となる審査基準データを保管する。審査基準に変更があった場合には、審査基準データを更新することを想定している。
- 審査結果は他の機能により参照される。
- 本パターンは、審査対象に対してシステムと承認者の両方が関与する審査プロセスを想定している。
- システムが審査対象への事前処理を実行し、承認者が事前処理の結果を基に審査結果を決定する。
- 審査対象データがストレージに追加されたことをトリガーにして、審査処理が自動起動する。Amazon EventBridgeを用い、ストレージに追加された審査対象データに関する通知を審査処理(事前)関数に送信する。
- なお、システムによる事前処理については、本機能ブロックの「システムによる自動審査：S3イベント通知による処理起動」のパターンに基づき構成している。システムによる自動審査の他のパターンを利用するバリエーションも有り得る。
- AWS Lambdaにより、審査対象への事前処理を行う。
- システムによるルールベースの判断(例. 入力された値が基準の範囲内か、入力された文字列が基準文字列と一致するか等)を事前処理として実行する。事前処理に必要となる審査基準データは、データベースから取得する。
- なお、審査の処理が複数ステップ(承認者への通知なども含む)にわたる場合には、申請・届出_電子決裁機能と組み合わせ、AWS StepFunctionsによるワークフローを構成しても良い。
- 承認者は、本パターンによって構成されるWebアプリケーションを利用して、システムによる事前処理を確認し、審査を行う。
- Webアプリケーションは、コンテナを利用し、フロントエンドとバックエンドそれぞれを別個のECSタスクとして動作させる。
- 承認者がインターネット経由でアクセスすることを前提とした場合は、フロントエンドはCDN+オブジェクトストレージで配信する構成へ置き換えることも可能である。
- ELBにWAF(※)を関連づけることにより、ネットワーク経由で行われる様々な攻撃からWebアプリケーションを保護する。
※WAFのルールグループについては非機能ブロック「セキュリティ_通信を介した攻撃への保護」を参照すること。 - 本パターンは、審査対象に対してシステム(生成AI)と承認者の両方が関与する審査プロセスを想定している。
- 生成AIが申請結果の案を作成し、承認者が申請結果の案を基に審査結果を決定する。
- 審査対象データがストレージに追加されたことをトリガーにして、審査処理が自動起動する。Amazon EventBridgeを用い、ストレージに追加された審査対象データに関する通知を審査処理関数に送信する。
- なお、システムによる事前処理については、本機能ブロックの「システムによる自動審査：S3イベント通知による処理起動」のパターンに基づき構成している。システムによる自動審査の他のパターンを利用するバリエーションも有り得る。
- AWS Lambdaにより、申請結果の案の作成処理を行う。AWS Lambdaの処理では、まず審査参考データを抽出し、審査参考データと審査対象データを生成AIに与え、申請結果の案を作成する。
- 過去の審査結果や審査基準等のドキュメントをAmazon S3に保管し、Amazon Kendraによって必要な審査参考データを検索する。
- Amazon Bedrockを生成AIとして利用し、審査参考データに基づいた審査結果の案を作成する。審査補助として、承認者に向けて特に注意して確認すべき点や、審査の際に確認すべき関連書類を提示するバリエーションも考えられる。
- なお、審査の処理が複数ステップ(承認者への通知なども含む)にわたる場合には、申請・届出_電子決裁機能と組み合わせ、AWS StepFunctionsによるワークフローを構成しても良い。
- 承認者は、本パターンによって構成されるWebアプリケーションを利用して、審査結果の案を確認する。
- Webアプリケーションは、コンテナを利用し、フロントエンドとバックエンドそれぞれを別個のECSタスクとして動作させる。
- 承認者がインターネット経由でアクセスすることを前提とした場合は、フロントエンドはCDN+オブジェクトストレージで配信する構成へ置き換えることも可能である。
- ELBにWAF(※)を関連づけることにより、ネットワーク経由で行われる様々な攻撃からWebアプリケーションを保護する。
※WAFのルールグループについては非機能ブロック「セキュリティ_通信を介した攻撃への保護」を参照すること。 - 本パターンは、審査対象に対してシステム(生成AI含む)と承認者の両方が関与する審査プロセスを想定している。システムが自動審査を行い、さらに、生成AIが審査対象の内容について特に注意して確認すべき点(申請誤りが疑われる点など)を挙げる。承認者は、システム(生成AI含む)の処理結果を基に審査結果を決定する。
- 審査対象データがストレージに追加されたことをトリガーにして、審査処理が自動起動する。Amazon EventBridgeを用い、ストレージに追加された審査対象データに関する通知を2つの審査処理関数に送信する。
- AWS Lambdaにより、審査対象への自動審査を行う。システムによるルールベースの判断(例. 入力された値が基準の範囲内か、入力された文字列が基準文字列と一致するか等)を実行する。自動審査に必要となる審査基準データは、データベースから取得する。
- AWS Lambdaにより、審査対象の内容について、承認者が特に注意して確認すべき点を挙げる。AWS Lambdaの処理では、まず審査参考データを抽出し、審査参考データと審査対象データを生成AIに与え、特に注意して確認すべき点を抽出する。
- 過去の審査結果や審査基準等のドキュメントをAmazon S3に保管し、Amazon Kendraによって必要な審査参考データを検索する。Amazon Bedrockを生成AIとして利用し、特に注意して確認すべき点(申請誤りが疑われる点など)を抽出する。
- なお、自動審査も含め、審査の処理が複数ステップ(承認者への通知なども含む)にわたる場合には、申請・届出_電子決裁機能と組み合わせ、AWS StepFunctionsによるワークフローを構成しても良い。
- 承認者は、本パターンによって構成されるWebアプリケーションを利用して、審査対象及びシステム(生成AI含む)の処理結果を確認する。システム(生成AI含む)の処理結果を参考にし、審査対象の審査を行う。
- Webアプリケーションは、コンテナを利用し、フロントエンドとバックエンドそれぞれを別個のECSタスクとして動作させる。
- 承認者がインターネット経由でアクセスすることを前提とした場合は、フロントエンドはCDN+オブジェクトストレージで配信する構成へ置き換えることも可能である。
- ELBにWAF(※)を関連づけることにより、ネットワーク経由で行われる様々な攻撃からWebアプリケーションを保護する。
※WAFのルールグループについては非機能ブロック「セキュリティ_通信を介した攻撃への保護」を参照すること。 - 本パターンは、審査対象に対して承認者が審査結果を決定することを想定している。
- 承認者は、本パターンによって構成されるWebアプリケーションを利用して、審査を行う。
- SPA（Single Page Application）における静的ファイル(HTML、JavaScript、CSS)をAWS Amplify のホスティングを利用して配信する。AWS AmplifyとCodeCommitなどのGitリポジトリを接続することで、Webアプリケーションの自動デプロイが可能となる。また、Webアプリケーション(フロントエンド)の開発においてAmplifyライブラリを使用することで、利用者認証の機能との連携などを容易に追加することができる。
- なお、WAFと関連付けできない点や、CloudFrontであれば可能な設定(カスタムエラーページなど)ができてない点等の制約について注意が必要である。
- ユーザーは他の機能ブロックにおいてユーザ認証を行い、認証トークンを取得する。
- 審査データの参照及び、結果入力はコンテナ上のバックエンドアプリケーションにより行われる。
- ELBにWAF(※)を関連づけることにより、インターネット経由で行われる様々な攻撃からWebアプリケーションを保護する。
※WAFのルールグループについては非機能ブロック「セキュリティ_通信を介した攻撃への保護」を参照すること。 - Webアプアプリケーションのリクエストの認可は認証系の機能ブロックにより発行されるトークンを検証することによって行われる。
- リクエストヘッダーに含まれるトークンの有効性を検証する。
- トークンが有効な場合のみ、リクエストは受理される。
- 認可されたリクエストは、バックエンドアプリケーションにて処理される。
- 処理結果は審査データ保管データベース・ストレージに保存される。
- 審査結果は他の機能により参照される。
5-1-3-1. 審査・承認_審査・承認機能
概要：
達成できる業務：
インタフェース例：
| インプット | 処理内容 | アウトプット |
|---|---|---|
| ・審査対象データの参照リクエスト | ・リクエストに応じてデータをクエリする | ・審査対象データ |
| ・審査結果の登録リクエスト | ・審査結果を登録する | ・届出・申請内容を返却 |
| ・審査結果の参照リクエスト | ・リクエストに応じてデータをクエリする | ・審査結果 |
| ・審査結果の更新リクエスト | ・リクエストに応じてデータを更新する | ・なし |
| ・審査結果の削除リクエスト | ・リクエストに応じてデータを削除する | ・なし |
連携機能ブロック：
審査・承認_審査・承認機能 (パターン1 承認者による審査)
ブロック実現例 （#コンテナバックエンド）
ブロック実現例 説明
[1]
[2]
[3]
[4]
[5]
審査・承認_審査・承認機能 (パターン2 システムによる自動審査：S3イベント通知による処理起動)
ブロック実現例 （#サーバレスイベント処理）
ブロック実現例 説明
[1]
[2]
[3]
[4]
審査・承認_審査・承認機能 (パターン3 システムによる自動審査：DocumentDB変更ストリームによる処理起動)
ブロック実現例
ブロック実現例 説明
[1]
[2]
[3]
[4]
審査・承認_審査・承認機能 (パターン4 システムによる事前処理・承認者による審査)
ブロック実現例 （#コンテナバックエンド #サーバレスイベント処理）
ブロック実現例 説明
[1]
[2]
[3]
審査・承認_審査・承認機能 (パターン5 AIによる審査補助・承認者による審査)
ブロック実現例 （#コンテナバックエンド #サーバレスイベント処理）
ブロック実現例 説明
[1]
[2]
[3]
審査・承認_審査・承認機能 (パターン6 システムによる自動審査・AIによる審査補助・承認者による審査)
ブロック実現例 （#サーバレスバックエンド #サーバレスフロントエンド #サーバレスイベント処理）
ブロック実現例 説明
[1]
[2]
[3]
[4]
審査・承認_審査・承認機能 (パターン7 承認者による審査:AmplifyによるWebアプリのホスティング)
ブロック実現例 （#コンテナバックエンド）
ブロック実現例 説明
[1]
[2]
[3]
[4]
[5]
[6]
5-1-4. データ管理
- 申請・届出等で登録された当該システム内の他機能でも扱えるように、必要に応じて加工（名寄せや個人情報マスキングなど）や情報付与（未納税金額や債権など）を行う。
- また、処理を行った後、情報を他機能が利用可能な形で保管する。
- データに形式変換等の処理を行う。
- 処理済みのデータを他機能が利用可能な形で保管する。
- データソースとなる機能
- 申請・届出_申請・届出機能
- 申請・届出_電子決裁機能
- 処理済みデータを参照する機能
- コンテンツ管理_Webページ（動的コンテンツ）公開機能
- データ管理_分析用ダッシュボード機能
- 本機能ブロックは他機能のデータストレージをデータソース対象とする。
- なお、マルチ AZ 構成の場合には、Reader インスタンスから読み取り処理を実施し、Writer インスタンスへの負荷軽減をすることが可能である。
- データソースのデータはGlueトリガーにより定期実行されるAWS Glueジョブにより抽出され、整形処理が行われた上で、処理済みデータ格納用ストレージへ保存される。
- 処理が完了したデータのストレージは、Amazon Aurora、Amazon DocumentDB、Amazon S3が想定される。
- 構造化データの場合はAmazon Auroraを、半構造化データの場合はDocumentDBを、柔軟なクエリの必要性が無い場合はAmazon S3がストレージとして推奨される。
- 処理済みのデータはコンテンツ管理_Webページ（動的コンテンツ）公開機能やデータ管理_分析用ダッシュボード機能により利用者（職員）へアクセスが提供される。
- 本機能ブロックは他機能のデータストレージをデータソース対象とする。
- データソースのデータはS3アップロードイベントにより起動するLambdaにより整形処理が行われた上で、処理済みデータ格納用ストレージへ保存される。
- 処理が完了したデータのストレージは、Amazon Aurora、Amazon DocumentDB、Amazon Redshift、Amazon S3が想定される。
- 構造化データの場合はAmazon AuroraないしはAmazon Redshiftを、半構造化データの場合はDocumentDBを、柔軟なクエリの必要性が無い場合はAmazon S3がストレージとして推奨される。なお、Amazon S3に保存されたデータはAmazon Athenaから読み取ることが可能である。
- 処理済みのデータはコンテンツ管理_Webページ（動的コンテンツ）公開機能やデータ管理_分析用ダッシュボード機能により利用者（職員）へアクセスが提供される。
- 本機能ブロックは他機能のデータストレージをデータソース対象とする。
- S3アップロードイベントにより起動するLambdaによりAWS Glueジョブを起動し、データソースのデータに対して整形処理を実施する。
- AWS Glueジョブにより処理されたデータはデータ格納用ストレージへ保存される。
- 処理が完了したデータのストレージは、Amazon Aurora、Amazon DocumentDB、Amazon S3が想定される。
- 構造化データの場合はAmazon Auroraを、半構造化データの場合はDocumentDBを、柔軟なクエリの必要性が無い場合はAmazon S3がストレージとして推奨される。
- 処理済みのデータはコンテンツ管理_Webページ（動的コンテンツ）公開機能やデータ管理_分析用ダッシュボード機能により利用者（職員）へアクセスが提供される。
- 本機能ブロックは他機能のデータストレージをデータソース対象とする。
- データソースのデータは各DBの差分ストリーム機能を利用し、ストリームのコンシューマーへと差分を連携する。
- AWS Lambdaを差分ストリームのコンシューマとして利用し、Kinesis Data Firehoseへ接続する。
- Kinesis Data Firehoseはバッファとして機能し、データ整形関数による個人情報マスキングやデータ形式変換などの処理も実現する。
- 処理済みのデータはDBまたはオブジェクトストレージへ保存される。
- 構造化データの場合はAmazon Auroraを、半構造化データの場合はDocumentDBを、柔軟なクエリの必要性が無い場合はAmazon S3がストレージとして推奨される。
- 処理済みのデータはデータへのアクセスを提供する他の機能ブロックにより利用される。
- 利用者からWebフォームやファイルにより送付されるデータを受領し、保管する。
- 利用者からWebフォームやファイルにより送付されるデータを受領し、保管する業務。
- SaaS上のアプリケーションのデータを収集し、保管する業務。
- 保管したデータを連携機能向けに別ストレージに保管する業務。
- Amazon DocumentDBから変更ストリームにより抽出する場合：1件（設定に依存し複数も可）
- Amazon DocumentDBからGlueにより抽出する場合：一括処理
- データ受領向けフロントエンドアプリの配信
- コンテンツ管理_Webページ（静的コンテンツ）公開機能
- 収集対象データの利用
- データ管理_統計処理機能
- データ管理_文書検索機能
- この機能は、他の機能により提供されるフロントエンドアプリからアクセスされることを想定する。
- またコンテンツを配信を担う他の機能ブロックによりWebフォームをユーザへ配信する。
- Webフォームへの入力データはREST APIで送信される。
- REST APIは、負荷分散用のElastic Load Balancing及びコンテナアプリケーション動作用のAmazon ECSにより構成する。
- ELBにWAF(※)を関連づけることにより、インターネット経由で行われる様々な攻撃からWebアプリケーションを保護する。
※WAFのルールグループについては非機能ブロック「セキュリティ_通信を介した攻撃への保護」を参照すること。 - Webフォームへの入力データはコンテナ上のバックエンドアプリケーションにより内容のチェックを行う。
- 内容に問題がない場合には、JSON形式にてDocumentDBへ保管する。
- Amazon DocumentDBに蓄積されたデータのうち、差分データのみを年次や月次等の低頻度で収集し静止断面を確保する場合には、AWS Glueを利用して、Amazon DocumentDBに蓄積されたデータのうち、差分データのみを同一フォーマットでAmazon S3へ一定期間ごとに収集する。
- また、AWS Glueによる差分データの収集では、コレクション単位ないしはドキュメント単位で収集することが可能である。
- 他の機能ブロックはWebフォームへの入力データを参照し分析等に利用することができる。
- この機能は、他の機能により提供されるフロントエンドアプリからアクセスされることを想定する。
- またコンテンツを配信を担う他の機能ブロックによりWebフォームをユーザへ配信する。
- Webフォームへの入力データはREST APIで送信される。
- REST APIは、負荷分散用のElastic Load Balancing及びコンテナアプリケーション動作用のAmazon ECSにより構成する。
- ELBにWAF(※)を関連づけることにより、インターネット経由で行われる様々な攻撃からWebアプリケーションを保護する。
※WAFのルールグループについては非機能ブロック「セキュリティ_通信を介した攻撃への保護」を参照すること。 - Webフォームへの入力データはコンテナ上のバックエンドアプリケーションにより内容のチェックを行う。
- 内容に問題がない場合には、JSON形式にてDocumentDBへ保管する。
- Lambdaを使用し、DocumentDBの変更ストリームから連携された変更内容をS3へ同一フォーマットで同期する。
- ただし、Lambdaが重複した変更内容を受け取る場合が想定されるため、LambdaにおいてS3へ収集済みのデータを確認した上で書き込む等の実装が必要である。
- 他の機能ブロックはWebフォームへの入力データを参照し分析等に利用することができる。
- 外部システムは、この機能が提供するREST APIの呼び出しに必要なトークンを連携機能を用いて取得する。
- 外部システムを起点とするデータ収集を行う場合、この機能が提供するREST APIを外部システムが呼び出す。
- REST APIは、負荷分散用のElastic Load Balancing及びコンテナアプリケーション動作用のAmazon ECSにより構成する。
- ELBにWAF(※)を関連づけることにより、インターネット経由で行われる様々な攻撃からWebアプリケーションを保護する。
※WAFのルールグループについては非機能ブロック「セキュリティ_通信を介した攻撃への保護」を参照すること。 - 収集したデータはコンテナ上のバックエンドアプリケーションにより内容のチェックを行う。
- 内容に問題がない場合には、JSON形式にてDocumentDBへ保管する。
- Amazon DocumentDBに蓄積されたデータのうち、差分データのみを年次や月次等の低頻度で収集し静止断面を確保する場合には、AWS Glueを利用して、Amazon DocumentDBに蓄積されたデータのうち、差分データのみを同一フォーマットでAmazon S3へ一定期間ごとに収集する。また、AWS Glueによる差分データの収集では、コレクション単位ないしはドキュメント単位で収集することが可能である。
- この機能を起点とするデータ収集を行う場合、外部システムが提供するREST APIをこの機能が呼び出す。外部システムのREST APIの呼び出しは、Amazon EventBridge Schedulerを用いて定期的にLambdaを実行することで実現する。 外部システムから取得するデータはJSON形式であると想定し、保管先はAmazon S3またはDocumentDBが考えられる。
- 他の機能ブロックは収集したデータを参照し分析等に利用することができる。
- 外部システムは、この機能が提供するREST APIの呼び出しに必要なトークンを連携機能を用いて取得する。
- 外部システムを起点とするデータ収集を行う場合、この機能が提供するREST APIを外部システムが呼び出す。
- REST APIは、負荷分散用のElastic Load Balancing及びコンテナアプリケーション動作用のAmazon ECSにより構成する。
- ELBにWAF(※)を関連づけることにより、インターネット経由で行われる様々な攻撃からWebアプリケーションを保護する。
※WAFのルールグループについては非機能ブロック「セキュリティ_通信を介した攻撃への保護」を参照すること。 - Webフォームへの入力データはコンテナ上のバックエンドアプリケーションにより内容のチェックを行う。
- 内容に問題がない場合には、JSON形式にてDocumentDBへ保管する。
- Lambdaを使用し、DocumentDBの変更ストリームから連携された変更内容をS3へ同一フォーマットで同期する。
- ただし、Lambdaが重複した変更内容を受け取る場合が想定されるため、LambdaにおいてS3へ収集済みのデータを確認した上で書き込む等の実装が必要である。
- この機能を起点とするデータ収集を行う場合、外部システムが提供するREST APIをこの機能が呼び出す。外部システムのREST APIの呼び出しは、Amazon EventBridge Schedulerを用いて定期的にLambdaを実行することで実現する。 外部システムから取得するデータはJSON形式であると想定し、保管先はAmazon S3またはDocumentDBが考えられる。
- 他の機能ブロックは収集したデータを参照し分析等に利用することができる。
- Amazon AppFlowを利用して、SaaSアプリケーションからのデータ取得を行う。Amazon AppFlow は、Salesforce、SAP、Google Analytics、などのSaaSアプリケーションとAWSのサービスとの間で、コードを記述することなくデータを転送できるサービスである。Amazon AppFlowを利用し、Saasアプリケーション上のデータをAmazon S3の収集データ蓄積ストレージに保管する。Amazon AppFlowでは、データの転送において、対象データの絞り込みやデータの変換も可能である。
- 他の機能ブロックは収集したデータを参照し分析等に利用することができる。
- この機能は、他の機能により提供されるフロントエンドアプリからアクセスされることを想定する。
- またコンテンツを配信を担う他の機能ブロックによりWebフォームをユーザへ配信する。
- 入力ファイルはREST APIで送信される。
- REST APIは、負荷分散用のElastic Load Balancing及びコンテナアプリケーション動作用のAmazon ECSにより構成する。
- ELBにWAF(※)を関連づけることにより、インターネット経由で行われる様々な攻撃からWebアプリケーションを保護する。
※WAFのルールグループについては非機能ブロック「セキュリティ_通信を介した攻撃への保護」を参照すること。 - コンテナ上のバックエンドアプリケーションによりデータおよびファイルの形式チェックを行う。
- 内容に問題がない場合はS3に保管される。ファイル保管によるS3通知によりLambdaをトリガーする。
- Lambdaのみで高精度な日本語に関するOCR処理は実現が困難のため、S3通知によりトリガーされたLambdaにより保管されたファイルを取得し、外部APIへ連携しOCR処理を実施する。
- OCR処理により抽出したメタデータ及び文字列データを他の機能が保持しているOpenSearchに保存する。
- 他の機能ブロックはOCR処理により抽出したメタデータ・文字列データに対して検索等実施することができる。
- 行政データ分析を行うためのダッシュボードの提供、および分析に必要な前処理やダッシュボード管理を行う。
- 分析者が対象データを可視化するために必要となる事前処理業務。
- 分析者が参照する分析用ダッシュボードの作成業務。
- 分析者が分析用ダッシュボードを分析する業務。
- 可視化対象データの収集・保管
- データ管理_データ連携機能
- データ管理_データ収集機能
- データ管理_大量データ取り込み機能
- 分析用ダッシュボードの公開
- データ管理_統計情報公開機能
- データ収集及び管理等を担う機能ブロックにより生成・蓄積されたデータを参照する。
- Glueを使用し可視化に必要な事前処理を必要に応じて実施する。
- 事前処理後のデータはS3へ保管し、メタデータはGlue Data Catalogで管理する。
- S3へ保管したデータをQuickSightにより可視化する。
- 分析者はQuickSightで可視化したデータへアクセスし、分析することが可能である。
- また単一ないしは複数のビジュアルを組み合わせて分析結果を作成し、ダッシュボードとして公開することが可能である。なお、ダッシュボードはPDFファイルとして出力することも可能である。
- 分析者が作成したダッシュボードは分析結果の公開を担う機能ブロックにより参照される。
- 行政データの統計処理を行う。
- 分析者が対象となるデータをETL処理する業務。
- 分析者が事前処理済みのデータを統計処理する業務。
- 分析者が統計処理後のデータを連携機能向けに保管する業務。
- ※統計処理データベースへのデータロードについては、採用する構成に依存し必要となる。
- ・Amazon Redshiftにより統計処理を実施する場合：データロード処理が必要
- ・Amazon Athenaにより統計処理を実施する場合：データロード処理が不要（S3内のデータセットを直接参照）
- 分析対象データの収集・保管
- データ管理_データ連携機能
- データ管理_データ収集機能
- データ管理_大量データ取り込み機能
- 統計処理結果の利用
- データ管理_分析用ダッシュボード機能
- データ管理_統計情報公開機能
- 利用者の認証
- 利用者認証_ユーザ認証機能（職員向け）
- データ収集及び管理等を担う機能ブロックにより生成・蓄積されたデータを参照する。
- Glueを使用し統計処理に必要な事前処理を実施する。
- 事前処理後のデータはS3へ保管し、メタデータはGlue Data Catalogで管理する。
- Glueを使用し、事前処理後のデータをRedshiftへロードする。
- 分析者はRedshiftのクエリエディタへブラウザからアクセスし、統計処理を実施する。
- 統計処理後のデータをS3へアンロードする。メタデータはGlue Data Catalogで管理する。
- 他の機能ブロックはS3へ保存された統計処理後のデータを参照し、可視化等に利用することが可能である。
- データ収集及び管理等を担う機能ブロックにより生成・蓄積されたデータを参照する。
- Glueを使用し統計処理に必要な事前処理を実施する。
- 事前処理後のデータはS3へ保管し、メタデータはGlue Data Catalogで管理する。
- 分析者はAthenaのクエリエディタへブラウザからアクセスし、Athenaを経由しS3に保管されたデータを直接参照し、統計処理を実施する。
- 統計処理後のデータをS3へアンロードする。メタデータはGlue Data Catalogで管理する。
- ただし、Athenaは処理のスキャン量に依存してコストがかかるため、処理頻度が高い場合にはRedshiftの採用を検討する。
- 他の機能ブロックはS3へ保存された統計処理後のデータを参照し、可視化等に利用することが可能である。
- データ収集及び管理等を担う機能ブロックにより生成・蓄積されたデータを参照する。
- Glueを使用し統計処理に必要な事前処理を実施する。
- 事前処理後のデータはS3へ保管し、メタデータはGlue Data Catalogで管理する。
- Glueを使用し、事前処理後のデータをRedshiftへロードする。
- 分析者はQuickSight専用コンソールからアクセスし、QuickSightからRedShiftへSQLを直接実行し、統計処理を実施する。>- 統計処理後のデータを可視化し、分析結果としてビジュアルを作成する。
- 分析者は作成したビジュアルから分析結果をCSVファイルまたはXSLXファイルにてエクスポートし、ダウンロードする。
- ただし、CSVファイルはビジュアルの形式に制限はないが、XSLXファイルはビジュアルの形式がピボットテーブルおよびテーブルチャートの場合にのみ利用可能である。
- 分析者はファイルアップロードを担う機能ブロックにより、分析結果のCSVファイルまたはXSLXファイルをストレージに保存する。
- 他の機能ブロックはS3へ保存された統計処理後のデータを参照し、可視化等に利用することが可能である。
- データ収集及び管理等を担う機能ブロックにより生成・蓄積されたデータを参照する。
- Glueを使用し統計処理に必要な事前処理を実施する。
- 事前処理後のデータはS3へ保管し、メタデータはGlue Data Catalogで管理する。
- 分析者はQuickSight専用コンソールからアクセスし、 QuickSightからAthenaへSQLを直接実行し、S3に保管されたデータを直接参照し、統計処理を実施する。
- 統計処理後のデータを可視化し、分析結果としてビジュアルを作成する。
- ただし、Athenaは処理のスキャン量に依存してコストがかかるため、処理頻度が高い場合にはRedshiftの採用を検討する。
- 分析者は作成したビジュアルから分析結果をCSVファイルまたはXSLXファイルにてエクスポートし、ダウンロードする。
- ただし、CSVファイルはビジュアルの形式に制限はないが、XSLXファイルはビジュアルの形式がピボットテーブルおよびテーブルチャートの場合にのみ利用可能である。
- 分析者はファイルアップロードを担う機能ブロックにより、分析結果のCSVファイルまたはXSLXファイルをストレージに保存する。
- 他の機能ブロックはS3へ保存された統計処理後のデータを参照し、可視化等に利用することが可能である。
- SPA（Single Page Application）における静的ファイル（HTML、JavaScript、CSS）をCloudFront及びS3で配信する。
- ファイルは高耐久なオブジェクトストレージであるS3に保管する。CloudFrontはCDNとしての機能を提供し、大量のリクエストにも低レイテンシーでの応答を実現する。
- またWAF(※)によりインターネット経由で行われる様々な攻撃からフロントエンド配信機能を保護する。
※WAFのルールグループについては非機能ブロック「セキュリティ_通信を介した攻撃への保護」を参照すること。 - 分析者は他の機能ブロックにおいてユーザ認証を行い、認証トークンを取得する。
- 統計処理はREST APIで送信される。
- REST APIはAPI Gateway及びECSにより構築される。
- またWAFによりインターネット経由で行われる様々な攻撃からAPIを保護する。
- APIリクエストの認可は認証系の機能ブロックにより発行されるトークンを検証することによって行われる。
- API GatewayはLambda Authorization機能により認証トークン検証関数を起動し、APIリクエストヘッダーに含まれるトークンの有効性を検証する。
- トークンが有効な場合のみ、APIリクエストは受理される。
- 認可された操作は、統計処理実行サーバーにより実行される。
- 統計処理実行サーバー内にはデータベースへ接続するためのJDBC等のドライバーを配置し接続する。
- データ収集及び管理等を担う機能ブロックにより生成・蓄積されたデータを参照する。
- Glueを使用し統計処理に必要な事前処理を実施する。
- 事前処理後のデータはS3へ保管し、メタデータはGlue Data Catalogで管理する。
- Glueを使用し、事前処理後のデータをRedshiftへロードする。
- 分析者はアプリケーションへブラウザからアクセスし、統計処理を実施する。
- 統計処理後のデータをS3へアップロードする。メタデータはGlue Data Catalogで管理する。
- 他の機能ブロックはS3へ保存された統計処理後のデータを参照し、可視化等に利用することが可能である。
- SPA（Single Page Application）における静的ファイル（HTML、JavaScript、CSS）をCloudFront及びS3で配信する。
- ファイルは高耐久なオブジェクトストレージであるS3に保管する。CloudFrontはCDNとしての機能を提供し、大量のリクエストにも低レイテンシーでの応答を実現する。
- またWAF(※)によりインターネット経由で行われる様々な攻撃からフロントエンド配信機能を保護する。
※WAFのルールグループについては非機能ブロック「セキュリティ_通信を介した攻撃への保護」を参照すること。 - 分析者は他の機能ブロックにおいてユーザ認証を行い、認証トークンを取得する。
- 統計処理はREST APIで送信される。
- REST APIはAPI Gateway及びLambdaにより構築される。
- またWAFによりインターネット経由で行われる様々な攻撃からAPIを保護する。
- APIリクエストの認可は認証系の機能ブロックにより発行されるトークンを検証することによって行われる。
- API GatewayはLambda Authorization機能により認証トークン検証関数を起動し、APIリクエストヘッダーに含まれるトークンの有効性を検証する。
- トークンが有効な場合のみ、APIリクエストは受理される。
- 認可された操作は、統計処理実行関数により実行される。
- 統計処理実行関数内においてAWS SDKを利用してデータベースへクエリを実行し、クエリ結果をストレージへ格納する。
- データ収集及び管理等を担う機能ブロックにより生成・蓄積されたデータを参照する。
- Glueを使用し統計処理に必要な事前処理を実施する。
- 事前処理後のデータはS3へ保管し、メタデータはGlue Data Catalogで管理する。
- 分析者はアプリケーションへブラウザからアクセスし、統計処理を実施する。
- 統計処理後のデータをS3へアップロードする。メタデータはGlue Data Catalogで管理する。
- 他の機能ブロックはS3へ保存された統計処理後のデータを参照し、可視化等に利用することが可能である。
- SPA（Single Page Application）における静的ファイル（HTML、JavaScript、CSS）をCloudFront及びS3で配信する。
- ファイルは高耐久なオブジェクトストレージであるS3に保管する。CloudFrontはCDNとしての機能を提供し、大量のリクエストにも低レイテンシーでの応答を実現する。
- またWAF(※)によりインターネット経由で行われる様々な攻撃からフロントエンド配信機能を保護する。
※WAFのルールグループについては非機能ブロック「セキュリティ_通信を介した攻撃への保護」を参照すること。 - 分析者は他の機能ブロックにおいてユーザ認証を行い、認証トークンを取得する。
- 統計処理はREST APIで送信される。
- REST APIはAPI Gateway及びECSにより構築される。
- またWAFによりインターネット経由で行われる様々な攻撃からAPIを保護する。
- APIリクエストの認可は認証系の機能ブロックにより発行されるトークンを検証することによって行われる。
- API GatewayはLambda Authorization機能により認証トークン検証関数を起動し、APIリクエストヘッダーに含まれるトークンの有効性を検証する。
- トークンが有効な場合のみ、APIリクエストは受理される。
- 認可された操作は、統計処理実行サーバーにより実行される。
- 統計処理実行サーバー内にはデータベースへ接続するためのJDBC等のドライバーを配置し接続する。
- データ収集及び管理等を担う機能ブロックにより生成・蓄積されたデータを参照する。
- Glueを使用し統計処理に必要な事前処理を実施する。
- 事前処理後のデータはS3へ保管し、メタデータはGlue Data Catalogで管理する。
- 分析者はアプリケーションへブラウザからアクセスし、統計処理を実施する。
- 統計処理後のデータをS3へアップロードする。メタデータはGlue Data Catalogで管理する。
- 他の機能ブロックはS3へ保存された統計処理後のデータを参照し、可視化等に利用することが可能である。
- 行政に係る統計データをダッシュボードとして公開する。
- 分析者が作成した統計処理後データ及び公開用ダッシュボードを公開する業務。
- 分析者が作成した統計処理後データ、公開用ダッシュボードの元データセットに対して事前処理を実施する業務。
- 分析者が事前処理後のデータを可視化した公開用ダッシュボードを作成する業務。
- 分析者が事前処理後のデータ及び公開用ダッシュボードを公開する業務。
- データ公開用フロントエンドアプリの配信
- コンテンツ管理_Webページ（静的コンテンツ）公開機能
- 公開対象データの生成
- データ管理_統計処理機能
- データ管理_分析用ダッシュボード機能
- データ管理_データ収集機能
- この機能は、他の機能により提供されるフロントエンドアプリからアクセスされることを想定する。
- またコンテンツを配信を担う他の機能ブロックにより統計情報を静的ファイル（CSVファイル、エクセル等）としてユーザへ配信する。
- 統計処理結果のファイルは、他の機能ブロックによって生成され、統計情報配信ストレージに格納される。
- この機能は、他の機能により提供されるフロントエンドアプリからアクセスされることを想定する。
- またコンテンツを配信を担う他の機能ブロックにより統計情報を静的ファイル（CSVファイル、エクセル等）としてユーザへ配信する。
- 公開対象となるデータは、他の機能ブロックによって生成されストレージに格納される。
- Glueを使用し公開に必要となる事前処理及びフォーマット変換を実施する。
- 事前処理後のデータは統計情報配信ストレージに格納される。
- この機能は、他の機能により提供されるフロントエンドアプリからアクセスされることを想定する。
- コンテンツを配信を担う他の機能ブロックにQuickSightダッシュボードのURLを表示し公開する。
- また必要に応じてQuickSightダッシュボードの埋め込みによる公開を実施する。
- 公開対象となるデータは、他の機能ブロックによって生成され、他の機能ブロック内のストレージに格納される。
- Glueを使用し他の機能ブロックにより生成された公開対象のデータに対して、公開に必要となる事前処理を実施する。
- 事前処理結果はストレージに格納される。
- QuickSightを使用し事前処理結果をストレージから読み込み、統計処理公開用のダッシュボードを作成する。
- 作成したダッシュボードのURL及び埋め込みを他の機能ブロックにより公開する。
- この機能は、他の機能により提供されるフロントエンドアプリからアクセスされることを想定する。
- コンテンツを配信を担う他の機能ブロックにQuickSightダッシュボードのURLを表示し公開する。
- また必要に応じてQuickSightダッシュボードの埋め込みによる公開を実施する。
- 統計処理公開用のQuickSightダッシュボードは他の機能により生成される。
- 蓄積した複数の文書（ファイルやWebコンテンツ）から特定キーワードを全文検索する。
- データに対し全文検索エンジンによる検索を行う。
- UIを提供する機能
- コンテンツ管理_Webページ（静的コンテンツ）公開機能
- 認証機能
- 利用者認証_ユーザ認証機能（国民向け）
- 利用者認証_ユーザ認証機能（企業ユーザ向け）
- 利用者認証_ユーザ認証機能（職員向け）
- データ生成機能
- データ管理_データ連携機能
- データ管理_データ収集機能
- この機能は、他の機能により提供されるフロントエンドアプリからアクセスされることを想定する。
- ユーザーは他の機能ブロックにおいてユーザ認証を行い、認証トークンを取得する。
- 全文検索の結果はREST APIとして提供される。REST APIはAPI Gateway及びLambdaにより構築される。
- またWAF(※)はインターネット経由で行われる様々な攻撃からAPIを保護する。
※WAFのルールグループについては非機能ブロック「セキュリティ_通信を介した攻撃への保護」を参照すること。 - APIリクエストの認可は認証系の機能ブロックにより発行されるトークンを検証することによって行われる。
- API GatewayはLambda Authorizer機能により認証トークン検証関数を起動し、APIリクエストヘッダーに含まれるトークンの有効性を検証する。
- トークンが有効な場合のみ、APIリクエストは受理される。
- 認可されたリクエストは、全文検索処理関数にて処理される。
- この関数はOpenSearchで全文検索を行い結果をユーザーへ返却する。
- OpenSearchへはLambdaを利用し差分データを取り込む。
- LambdaはEventBrdigeにより一定間隔で実行される。
- 元データがS3に保管されている場合は、S3のアップデートイベントをトリガーとしてLambdaを起動することも選択肢となる。
- 全文検索の対象となるデータは他の機能により生成される。
- データはS3やRDSに保管されていると想定する。
- この機能は、他の機能により提供されるフロントエンドアプリからアクセスされることを想定する。
- ユーザーは他の機能ブロックにおいてユーザ認証を行い、認証トークンを取得する。
- 全文検索の結果はREST APIとして提供される。REST APIはAPI Gateway及びLambdaにより構築される。
- またWAF(※)はインターネット経由で行われる様々な攻撃からAPIを保護する
※WAFのルールグループについては非機能ブロック「セキュリティ_通信を介した攻撃への保護」を参照すること。 - APIリクエストの認可は認証系の機能ブロックにより発行されるトークンを検証することによって行われる。
- API GatewayはLambda Authorizer機能により認証トークン検証関数を起動し、APIリクエストヘッダーに含まれるトークンの有効性を検証する。
- トークンが有効な場合のみ、APIリクエストは受理される。
- 認可されたリクエストは、全文検索処理関数にて処理される。
- この関数はOpenSearchで全文検索を行い結果をユーザーへ返却する。
- OpenSearchへはECSタスクを利用し差分データを取り込む。
- ECSタスクはEventBridgeにより一定間隔で実行される。
- 元データがS3に保管されている場合は、S3のアップデートイベントをトリガーとしてECSタスクを起動することも選択肢となる。
- 全文検索の対象となるデータは他の機能により生成される。
- データはS3やRDSに保管されていると想定する。
- この機能は、他の機能により提供されるフロントエンドアプリからアクセスされることを想定する。
- ユーザーは他の機能ブロックにおいてユーザ認証を行い、認証トークンを取得する。
- 全文検索の結果はREST APIとして提供される。REST APIはAPI Gateway及びLambdaにより構築される。
- またWAF(※)はインターネット経由で行われる様々な攻撃からAPIを保護する。
※WAFのルールグループについては非機能ブロック「セキュリティ_通信を介した攻撃への保護」を参照すること。 - APIリクエストの認可は認証系の機能ブロックにより発行されるトークンを検証することによって行われる。
- API GatewayはLambda Authorizer機能により認証トークン検証関数を起動し、APIリクエストヘッダーに含まれるトークンの有効性を検証する。
- トークンが有効な場合のみ、APIリクエストは受理される。
- 認可されたリクエストは、全文検索処理関数にて処理される。
- この関数はOpenSearchで全文検索を行い結果をユーザーへ返却する。
- Lambdaでコンシューマ関数を作成し、変更イベントをトリガーとする。
- OpenSearchへはKinesis Data Firehoseを利用して接続することにより、データ整形関数の呼び出し及びバッファリングを可能にする。
- 全文検索の対象となるデータは他の機能により生成されAmazon RDS又はAmazon DocumentDBへ保存される。
- 各DBの差分ストリーム機能を利用し、ストリームのコンシューマーへと差分を連携する。
- IoTデバイスやセンサからの観測データを取り込む。
- IoTデバイスやセンサからの観測データを取り込むため、IoTデバイスと利用システムとの接続性の確立やデータ取り込みパイプラインとの連携を行う
- データを取り込むパイプライン機能
- データ管理_大量データ取り込み機能
- MQTT又はHTTPS通信が利用可能である観測機器をIoT Coreへ接続し管理する。
- IoT Coreは観測機器が提示するクライアント証明書によるデバイス認証や、IoTデバイスのモニタリング等を行う。
- 観測機器とAWSクラウドの通信が不安定な場合や、デバイス間通信を実現する場合はIoT Greengrassをインストールしたエッジデバイスを利用する。
- IoT Greengrassのストリームマネージャー機能によりエッジでのデータのストリーム処理なども実現可能である。
- 観測値はIoT Coreから、連携機能のパイプラインへ送信される。
- 高頻度に送られてくる観測データやリアルタイム集計が必要となるデータの管理、集計、保存を行う。
- ストリーミングデータをリアルタイムに収集及び分析処理する業務。
- ストリーミングデータを形式を変更せずにリアルタイムに蓄積する業務。
- 蓄積されたストリーミングデータの参照及び利用
- データ管理_統計処理機能
- データ管理_分析用ダッシュボード機能
- 計測機器やアプリケーション等のストリーミングデータにおけるデータソース及びプロデューサが存在することを想定する。
- AWS外部にデータソース及びプロデューサが存在していること前提とした構成図となるが、AWS内部に存在することも想定される。
- Kinesis Data Streamsによりストリーミングデータを収集し、リアルタイム分析が必要な場合にはAmazon Managed Service for Apache Flink※へ連携する。
- リアルタイム分析が不要の場合にはKinesis Data Firehoseへ連携する。
- Amazon Managed Service for Apache Flink※によりストリーミングデータに対してリアルタイムで分析処理を実施する。
- 分析処理後のストリーミングデータをS3へ蓄積する。
- S3へ蓄積する前にETL処理が必要である場合にはKinesis Data Firehoseへ連携する。
- Kinesis Data Firehoseにより分析処理後のストリーミングデータへETL処理を実施し、S3へ保管する。
- メタデータはGlue Data Catalogで管理する。
- リアルタイムでの分析が不要の場合にはKinesis Data Firehoseにより形式の変更なしにストリーミングデータをS3へ保管し、メタデータはGlue Data Catalogで管理する。
- 他の機能ブロックはS3へ保存されたストリーミングデータを参照し、分析等に利用することが可能である。
- 2023/8/30に、Amazon Kinesis Data Analytics から Amazon Managed Service for Apache Flink へサービス名称変更
- 観測機器の管理、接続及び観測データの受信は他の連携機能によって実装される。
- 本機能では受信した観測データを取り込むパイプライン機能を提供する。
- Kinesis Data Streamsによりストリーミングデータを収集し、リアルタイム分析が必要な場合にはAmazon Managed Service for Apache Flink※へ連携する。
- リアルタイム分析が不要の場合にはKinesis Data Firehoseへ連携する。
- Amazon Managed Service for Apache Flink※によりストリーミングデータに対してリアルタイムで分析処理を実施する。
- 分析処理後のストリーミングデータをS3へ蓄積する。
- S3へ蓄積する前にETL処理が必要である場合にはKinesis Data Firehoseへ連携する。
- Kinesis Data Firehoseにより分析処理後のストリーミングデータへETL処理を実施し、S3へ保管する。
- メタデータはGlue Data Catalogで管理する。
- リアルタイムでの分析が不要の場合にはKinesis Data Firehoseにより形式の変更なしにストリーミングデータをS3へ保管し、メタデータはGlue Data Catalogで管理する。
- 他の連携機能はS3へ保存されたストリーミングデータを参照し、分析等に利用することが可能である。
- 2023/8/30に、Amazon Kinesis Data Analytics から Amazon Managed Service for Apache Flink へサービス名称変更
- 位置情報データを視覚的に表示する。
- 位置検索、ルート計算などの地理空間機能をアプリケーションに統合する。
- 地図表示や施設位置検索、経路計算、エリア入退出検知など、地図操作に関する業務を行う。
- UIを提供する機能
- コンテンツ管理_Webページ(静的コンテンツ)公開機能
- 認証機能
- 利用者認証_ユーザ認証機能（国民向け）
- 利用者認証_ユーザ認証機能（企業向け）
- 利用者認証_ユーザ認証機能（職員向け）
- データ保管機能
- データ管理_データ連携機能
- データ管理_データ収集機能
- メッセージ通知機能
- 利用者通知_メッセージ通知機能
- この機能は、他の機能により提供されるフロントエンドアプリからアクセスされることを想定する。
[2] - ユーザーは他の機能ブロックにおいてユーザ認証を行い、認証トークンを取得する。
[3] - 地図表示機能はAWS Location Service Client SDKを通じて提供される。クライアントアプリケーションからのリクエストは、SDK経由でAmazon Location Serviceに直接送信される。
- Amazon Location Serviceの各機能（Map、Place、Routes、Geofence、Track）を利用して地図表示、施設検索、経路計算、エリア入退出検知などの処理が行われ、結果がクライアントアプリケーションに返却される。
- なお、Amazon Location Serviceの機能群は、必ずしも全て利用する必要はなく、要件に応じて必要なものだけを利用することができる。
[4] - エリア入退出検知時は、他の機能ブロックにおいて利用者通知が実行される。
[5] - 位置情報の変更が発生した場合はEventBridgeによって変更通知イベントが発行される。
- このイベントをトリガーとしてLambda関数が起動し、差分データの取り込みや統計処理などが実行される。
[6] - 位置情報データは統計処理のために他の機能ブロックに保存され、公共施設の利用状況分析や災害時の避難所の需要予測、エリア別来訪者数の把握などに活用される。
5-1-4-1. データ管理_データ連携機能
概要：
達成できる業務：
インタフェース例：
| インプット | 処理内容 | アウトプット |
|---|---|---|
| ・他機能が出力するデータ | ・データ変換処理 ・個人情報マスキング | ・処理済みデータ |
連携機能ブロック：
データ管理_データ連携機能（パターン1 データベースサービスとして利用）
ブロック実現例 （#サーバレスデータ連携）
ブロック実現例 説明
[1]
[2]
[3]
[4]
データ管理_データ連携機能（パターン2 S3をデータソースとして利用・Lambda利用）
ブロック実現例 （#サーバレスデータ連携）
ブロック実現例 説明
[1]
[2]
[3]
[4]
データ管理_データ連携機能（パターン3 S3をデータソースとして利用・Glue利用）
ブロック実現例 （#サーバレスデータ連携）
ブロック実現例 説明
[1]
[2]
[3]
[4]
データ管理_データ連携機能（パターン4 リアルタイム）
ブロック実現例 （#ストリーム処理）
ブロック実現例 説明
[1]
[2]
[3]
[4]
[5]
補足：
[3]について、連携対象データの変更量が比較的少なく、データ連携のリアルタイム性が重視される場合には、低レイテンシーを実現するためにAmazon Kinesis Data Firehoseによるバッファリングを利用せず、Lambda関数のみでデータの処理と保存を行う構成が有効な選択肢となる。
5-1-4-2. データ管理_データ収集機能
概要：
達成できる業務：
インタフェース例：
| インプット | 処理内容 | アウトプット |
|---|---|---|
| ・登録用のWebフォームデータ（1件） | ・受信したWebフォームの内容をデータとして保管する。 | ・なし |
| ・登録用のファイルデータ（1件） | ・受信したファイルをデータとして保管する。 | ・なし |
| ・保管済みのWebフォームデータ（1件/一括）※ | ・保管済みのWebフォームデータを連携機能向けに処理し、結果を別ストレージへ格納する。 | ・別ストレージへ格納された連携機能向けの処理済みデータ |
| ・登録用のSaaS上データ | SaaSから受信したデータを保管する。 | ・なし |
| ・保管済みのファイルデータ（1件） | ・受信したファイルに対して連携機能向けにOCR処理を実施する。 ・OCR処理により抽出したメタデータ及び文字列データをデータベースに保管する。 | ・OCR処理により抽出したメタデータ及び文字列データ |
※保管済みのWebフォームデータ連携は、採用する構成に依存し処理方式が異なる。
連携機能ブロック：
データ管理_データ収集機能（パターン1 Webフォーム利用・静止断面確保）
ブロック実現例 （#コンテナバックエンド #サーバレスデータ連携）
ブロック実現例 説明
[1]
[2]
[3]
[4]
[5]
データ管理_データ収集機能（パターン2 Webフォーム利用・差分データをニアリアルタイム等で収集）
ブロック実現例 （#コンテナバックエンド）
ブロック実現例 説明
[1]
[2]
[3]
[4]
[5]
データ管理_データ収集機能（パターン3 外部システム連携・静止断面確保）
ブロック実現例 （#コンテナバックエンド #サーバレスデータ連携 #サーバレスイベント処理）
ブロック実現例 説明
[1]
[2]
[3]
[4]
[5]
[6]
データ管理_データ収集機能（パターン4 外部システム連携・差分データをニアリアルタイム等で収集）
ブロック実現例 （#コンテナバックエンド #サーバレスイベント処理）
ブロック実現例 説明
[1]
[2]
[3]
[4]
[5]
[6]
データ管理_データ収集機能（パターン5 外部システム連携・SaaS利用）
ブロック実現例
ブロック実現例 説明
[1]
[2]
補足：
本機能ブロックを利用する際には、Amazon AppFlowのサポート状況を事前に確認することが推奨される。収集対象とするSaaSそのものに対するサポートがあるか、また、SaaSの中でも収集対象とするデータに対するサポートがあるか、どのタイプのデータ転送トリガー（オンデマンド、スケジュール、イベント）がサポートされているか、等の確認を行うことが推奨される。
データ管理_データ収集機能（パターン6 ファイル/OCR）
ブロック実現例 （#コンテナバックエンド #サーバレスイベント処理）
ブロック実現例 説明
[1]
[2]
[3]
[4]
[5]
[6]
5-1-4-3. データ管理_分析用ダッシュボード機能
概要：
達成できる業務：
インタフェース例：
| インプット | 処理内容 | アウトプット |
|---|---|---|
| ・連携機能により生成された可視化対象となるデータセット（単一/複数） | ・単一及び複数のデータセットに対して可視化に必要となる事前処理を実施する。 | ・事前処理後のデータセット |
| ・事前処理後のデータセット | ・事前処理後のデータセットを対象として分析用ダッシュボードを作成する。 | ・事前処理後のデータセットを可視化した分析用ダッシュボード |
| ・可視化した分析用ダッシュボード | ・可視化データを分析し、分析結果としてまとめる。 | ・可視化した分析用ダッシュボードより分析した結果 |
連携機能ブロック：
データ管理_分析用ダッシュボード機能
ブロック実現例 （#サーバレスデータ連携）
ブロック実現例 説明
[1]
[2]
[3]
[4]
[5]
5-1-4-4. データ管理_統計処理機能
概要：
達成できる業務：
インタフェース例：
| インプット | 処理内容 | アウトプット |
|---|---|---|
| ・連携機能により生成された統計処理対象となるデータセット（単一/複数） | ・単一及び複数のデータセットに対して統計処理に必要となる事前処理を実施し、ストレージに格納する。 | ・事前処理後のデータセット |
| ・ストレージに格納された事前処理後のデータセット | ・分析処理を実施するデータベースへのロード処理を実施する。※ | ・統計処理データベースから参照可能な分析対象のデータセット |
| ・統計処理データベースから参照可能な分析対象のデータセット ・分析者が入力した統計処理用のSQL | ・SQLを使用して統計処理を実施し、処理結果をストレージへ格納する。 | ・統計処理後の処理結果 |
連携機能ブロック：
データ管理_統計処理機能（パターン1 高頻度かつ大規模なデータ分析を実施する場合・クエリエディタ利用）
ブロック実現例 （#サーバレスデータ連携）
ブロック実現例 説明
[1]
[2]
[3]
[4]
[5]
データ管理_統計処理機能（パターン2 低頻度かつ中規模なデータ分析を実施する場合・クエリエディタ利用）
ブロック実現例 （#サーバレスデータ連携）
ブロック実現例 説明
[1]
[2]
[3]
[4]
データ管理_統計処理機能（パターン3 高頻度かつ大規模なデータ分析を実施する場合・QuickSight利用）
ブロック実現例 （#サーバレスデータ連携）
ブロック実現例 説明
[1]
[2]
[3]
[4]
[5]
[6]
[7]
補足：
[2]および[3]について、Amazon Redshiftへの自動データ取り込み機能(Zero-ETL)をサポートするデータベースサービス(例. Amazon Aurora)からデータを取り込む場合には、AWS Glueによる事前処理やデータロード処理は不要とする選択肢もある。
データ管理_統計処理機能（パターン4 低頻度かつ中規模なデータ分析を実施する場合・QuickSight利用）
ブロック実現例 （#サーバレスデータ連携）
ブロック実現例 説明
[1]
[2]
[3]
[4]
[5]
[6]
データ管理_統計処理機能（パターン5 高頻度かつ大規模なデータ分析を実施する場合・ECS利用）
ブロック実現例 （#コンテナバックエンド #サーバレスフロントエンド #サーバレスデータ連携）
ブロック実現例 説明
[1]
[2]
[3]
[4]
[5]
[6]
[7]
[8]
[9]
[10]
データ管理_統計処理機能（パターン6 低頻度かつ中規模なデータ分析を実施する場合・Lambda利用）
ブロック実現例 （#サーバレスバックエンド #サーバレスフロントエンド #サーバレスデータ連携）
ブロック実現例 説明
[1]
[2]
[3]
[4]
[5]
[6]
[7]
[8]
[9]
データ管理_統計処理機能（パターン7 低頻度かつ中規模なデータ分析を実施する場合・ECS利用）
ブロック実現例 （#コンテナバックエンド #サーバレスフロントエンド #サーバレスデータ連携）
ブロック実現例 説明
[1]
[2]
[3]
[4]
[5]
[6]
[7]
[8]
[9]
5-1-4-5. データ管理_統計情報公開機能
概要：
達成できる業務：
インタフェース例：
| インプット | 処理内容 | アウトプット |
|---|---|---|
| ・連携機能により生成された統計処理後データないしは公開用ダッシュボード ・事前処理後のデータないしは事前処理後のデータセットを可視化した公開用ダッシュボード※ | ・対象となるデータないしは公開用ダッシュボードを静的コンテンツとして配信する処理を実施する。 | ・データ及び公開用ダッシュボードの公開 |
| ・連携機能により生成された統計処理後データ、公開用ダッシュボードの元データセット※ | ・公開前の事前処理を実施し、データマスキングやファイルフォーマット等の変換を実施する。 | ・事前処理後のデータ |
| ・ストレージに格納された事前処理後のデータセット※ | ・事前処理後のデータセットを対象として公開ダッシュボードを作成する。 | ・事前処理後のデータセットを可視化した公開用ダッシュボード |
※連携機能により生成された統計処理後のデータ、公開用ダッシュボードに関して直接公開可能ではない場合に必要となる処理である。
連携機能ブロック：
データ管理_統計情報公開機能（パターン1 ファイルによる公開：事前処理なし）
ブロック実現例
ブロック実現例 説明
[1]
[2]
データ管理_統計情報公開機能（パターン2 ファイルによる公開：事前処理あり）
ブロック実現例 （#サーバレスデータ連携）
ブロック実現例 説明
[1]
[2]
[3]
データ管理_統計情報公開機能（パターン3 ダッシュボードによる公開：事前処理あり）
ブロック実現例 （#サーバレスデータ連携）
ブロック実現例 説明
[1]
[2]
[3]
[4]
データ管理_統計情報公開機能（パターン4 ダッシュボードによる公開：事前処理なし）
ブロック実現例
ブロック実現例 説明
[1]
[2]
5-1-4-6. データ管理_文書検索機能
概要：
達成できる業務：
インタフェース例：
| インプット | 処理内容 | アウトプット |
|---|---|---|
| ・検索リクエスト | ・全文検索エンジンによる検索処理 | ・検索結果 |
| ・検索対象となるデータ | ・データ整形処理 ・OpenSearchクラスターへのデータ取り込み | ・なし |
連携機能ブロック：
データ管理_文書検索機能（パターン1 Lambda利用）
ブロック実現例 （#サーバレスバックエンド #サーバレスイベント処理）
ブロック実現例 説明
[1]
[2]
[3]
[4]
[5]
[6]
[7]
データ管理_文書検索機能（パターン2 ECS利用）
ブロック実現例 （#サーバレスバックエンド #サーバレスイベント処理）
ブロック実現例 説明
[1]
[2]
[3]
[4]
[5]
[6]
[7]
データ管理_文書検索機能（パターン3 リアルタイム取り込みの場合）
ブロック実現例 （#サーバレスバックエンド #サーバレスイベント処理 ストリーム処理）
ブロック実現例 説明
[1]
[2]
[3]
[4]
[5]
[6]
[7]
5-1-4-7. データ管理_IoT連携機能
概要：
達成できる業務：
インタフェース例：
| インプット | 処理内容 | アウトプット |
|---|---|---|
| ・観測データ | ・観測データを取り込みパイプラインへ送信。 | ・観測データ |
連携機能ブロック：
データ管理_IoT連携機能
ブロック実現例
ブロック実現例 説明
[1]
[2]
[3]
5-1-4-8. データ管理_大量データ取り込み機能
概要：
達成できる業務：
インタフェース例：
| インプット | 処理内容 | アウトプット |
|---|---|---|
| ・データソース及びプロデューサーから生成される収集対象のストリーミングデータ | ・受信した収集対象のストリーミングデータに対して分析処理を実施し、ストリーミングデータとして再配信する。 ・再配信したストリーミングデータをリアルタイムにストレージへ保管する。 | ・蓄積された分析後のストリーミングデータ |
| ・データソース及びプロデューサーから生成される収集対象のストリーミングデータ | ・受信した収集対象のデータを形式を変更せずにリアルタイムにストレージへ保管する。 | ・形式を変更せずに蓄積されたストリーミングデータ |
連携機能ブロック：
データ管理_大量データ取り込み機能 （パターン1 データプロデューサからの直接取り込み）
ブロック実現例 （#ストリーム処理）
ブロック実現例 説明
[1]
[2]
[3]
[4]
[5]
[6]
[注]
データ管理_大量データ取り込み機能 （パターン2 データ管理_IoT連携機能との連携）
ブロック実現例 （#ストリーム処理）
ブロック実現例 説明
[1]
[2]
[3]
[4]
[5]
[6]
[注]
5-1-4-9. データ管理_地図表示機能
概要：
達成できる業務：
インタフェース例：
| インプット | 処理内容 | アウトプット |
|---|---|---|
| ・地図表示リクエスト | ・位置情報を地図座標に変換する。 ・指定位置のポイントマーカ情報を取得する。 ・位置情報と地図タイルデータ結合する。 | ・地図画面表示 ・施設位置のポイントマーカ表示 |
| ・施設名や住所などの検索キーワード入力 | ・検索キーワードから地理座標情報を検索する。 ・検索結果の地理座標情報を取得する。 ・検索結果の地図上へのマッピングを行う。 | ・検索結果の地理座標情報 ・地図上の検索結果表示 |
| ・出発地点と目的地の座標情報 ・経路計算リクエスト | ・地点間の最適経路を計算する。 ・交通情報を考慮した経路最適化を行う。 ・移動時間と距離を算出する。 | ・最適経路情報 ・移動時間・距離情報 ・地図上の経路表示 |
| ・デバイスの位置情報 ・監視対象エリア情報 | ・監視対象エリアの地理的境界を登録する。 ・デバイス位置情報の継続的な追跡を行う。 ・エリア入退出イベントの検知と通知を行う。 ・位置データを統計処理用に保存する。 | ・エリア入退出通知 ・通知メール送信 ・位置情報履歴データ |
連携機能ブロック：
データ管理_地図表示機能
ブロック実現例
ブロック実現例 説明
[1]
5-1-5. 利用者通知
- 利用者に対して申請・届出を行った案件に関連する通知や手続に関する案内を行う。
- 利用者に対して、更新があったことを連絡する業務。
- 通知の送信をリクエストする機能
- 申請・届出_申請・届出機能
- 審査・承認_審査・承認機能
- 申請・届出_申請・届出機能等の他の機能ブロックが、通知送信のリクエストを送信する。
- 通知送信は、疎結合な非同期処理とし、Amazon SQSをメッセージキューとして利用する。
- メッセージキュー(Amazon SQS)へ通知送信のリクエストが送信されたことを契機として、AWS Lambdaが自動的に起動する。AWS Lambdaはプログラムの実行環境をサーバレスで提供するものであり、通知送信処理の実行環境を容易に構築可能である。
- AWS Lambda内の処理で、通知メールの本文等のコンテンツを作成し、Amazon SESへ通知メール送信をリクエストする。
- 利用者への通知メール送信には、マネージドサービスであるAmazon SESを利用する。Amazon SESを利用することにより、自前でのメールサーバ構築が不要となる。
- 申請・届出_申請・届出機能等の他の機能ブロックが、通知送信のリクエストを送信する。
- 通知送信は、疎結合な非同期処理として、Amazon SQSをメッセージキューとして利用する。
- メッセージキュー（Amazon SQS）へ通知送信のリクエストが送信されたことを契機として、AWS Lambdaが自動的に起動する。
- AWS Lambdaはプログラムの実行環境をサーバレスで提供するものであり、通知送信処理の実行環境を容易に構築可能である。
- AWS Lambda内の処理で、プッシュ通知のタイトルや本文等のコンテンツを作成し、Amazon Pinpointへプッシュ通知の送信をリクエストする。
- 利用者のモバイル端末へのSMSもしくはプッシュ通知の送信には、マネージドサービスであるAmazon Pinpointを利用する。>- Amazon Pinpointを利用して、利用者への個別の通知の送信が可能である。
- Amazon Pinpointは、Android向けのFirebase Cloud Messaging （FCM）や、iOS向けのApple プッシュ通知サービス （APNS）などのプッシュ通知サービスをサポートしている。
- なお、FCMやAPNS等のプッシュ通知サービスの利用のためには、プッシュ通知サービス側での認証情報の設定が必要である。
- 緊急性のあるメッセージをあらかじめ登録されているメールアドレスやSMSなどにアラート通知する。
- 利用者に対して、更新があったことを連絡する業務。
- 通知の送信をリクエストする機能
- 申請・届出_申請・届出機能
- 審査・承認_審査・承認機能
- 申請・届出_申請・届出機能等の他の機能ブロックが、通知送信のリクエストを送信する。
- 通知送信は、疎結合な非同期処理とし、Amazon SQSをメッセージキューとして利用する。
- メッセージキュー（Amazon SQS）へ通知送信のリクエストが送信されたことを契機として、AWS Lambdaが自動的に起動する。
- AWS Lambdaはプログラムの実行環境をサーバレスで提供するものであり、通知送信処理の実行環境を容易に構築可能である。
- AWS Lambda内の処理で、プッシュ通知のタイトルや本文等のコンテンツを作成し、Amazon Pinpointへプッシュ通知の送信をリクエストする。
- 利用者のモバイル端末へのプッシュ通知の送信には、マネージドサービスであるAmazon Pinpointを利用する。
- Amazon Pinpointを利用して、利用者への個別のプッシュ通知の送信が可能である。
- Amazon Pinpointは、Android向けのFirebase Cloud Messaging （FCM）や、iOS向けのApple プッシュ通知サービス （APNS）などのプッシュ通知サービスをサポートしている。
- なお、FCMやAPNS等のプッシュ通知サービスの利用のためには、プッシュ通知サービス側での認証情報の設定が必要である。
- 緊急性のあるメッセージをあらかじめ登録されているメールアドレスやSMSなどにアラート通知する。
- 利用者に対して、注意喚起を促すための連絡を行う業務。
- 通知の送信をリクエストする機能
- 通知の一斉送信に関する管理を提供する機能
- コンテンツ管理_Webページ（静的コンテンツ）公開機能
- コンテンツ管理_Webページ（動的コンテンツ）公開機能
- 申請・届出_申請・届出機能等の他の機能ブロックが、通知送信のリクエストを送信する。
- 通知送信は、疎結合な非同期処理とし、Amazon SQSをメッセージキューとして利用する。
- メッセージキュー（Amazon SQS）へ通知送信のリクエストが送信されたことを契機として、AWS Lambdaが自動的に起動する。
- AWS Lambdaはプログラムの実行環境をサーバレスで提供するものであり、通知送信処理の実行環境を容易に構築可能である。
- AWS Lambda内の処理で、通知メールの本文等のコンテンツを作成し、Amazon SES(※)へ通知メール送信をリクエストする。
※Amazon SESのメール送信については、アクセスキーが不要なIAMロールを使ったSES APIの利用を推奨。 - 利用者への通知メール送信には、マネージドサービスであるAmazon SESを利用する。
- Amazon SESを利用することにより、自前でのメールサーバ構築が不要となる。
- 申請・届出_申請・届出機能等の他の機能ブロックが、通知送信のリクエストを送信する。
- 通知送信は、疎結合な非同期処理とし、Amazon SQSをメッセージキューとして利用する。
- メッセージキュー（Amazon SQS）へ通知送信のリクエストが送信されたことを契機として、AWS Lambdaが自動的に起動する。
- AWS Lambdaはプログラムの実行環境をサーバレスで提供するものであり、通知送信処理の実行環境を容易に構築可能である。
- AWS Lambda内の処理で、プッシュ通知のタイトルや本文等のコンテンツを作成し、Amazon Pinpointへプッシュ通知の送信をリクエストする。
- 利用者のモバイル端末へのSMSもしくはプッシュ通知の送信には、マネージドサービスであるAmazon Pinpointを利用する。>- Amazon Pinpointを利用して、利用者への個別の通知の送信が可能である。
- Amazon Pinpointは、Android向けのFirebase Cloud Messaging （FCM）や、iOS向けのApple プッシュ通知サービス （APNS）などのプッシュ通知サービスをサポートしている。
- また、Amazon Pinpointでは、メールによる通知の送信もサポートしている。
- 通知の一斉送信は、アラートの発報が必要なイベントの発生に合わせて自動化することが可能である。
- 連携機能がトリガーとなり、通知送信用キューに、通知の送信リクエストを送信する。
- 通知送信は、疎結合な非同期処理とし、Amazon SQSをメッセージキューとして利用する。
- メッセージキュー（Amazon SQS）へ通知送信のリクエストが送信されたことを契機として、AWS Lambdaが自動的に起動する。
- AWS Lambdaはプログラムの実行環境をサーバレスで提供するものであり、通知送信処理の実行環境を容易に構築可能である。
- AWS Lambda内の処理で、通知の本文等のコンテンツを作成し、Amazon. Pinpointへ通知送信をリクエストする。
- 利用者への通知には、マネージドサービスであるAmazon Pinpointを利用する。
- Amazon Pinpointでは、Eメール、SMS、プッシュ通知による通知の送信をサポートしている。
- 通知の一斉送信は、運用者が手動で実行することが可能である。一斉送信に関する管理機能は連携機能により提供される。
- 連携機能において、一斉送信の宛先となるユーザを抽出し、抽出結果をAmazon S3に保存する。
- Amazon Pinpointでは、Amazon S3に保存されたファイルをインポートし、通知の宛先（セグメント）を作成することが可能である。
- また、連携機能を通じて、運用者が通知の内容や通知のタイミングなどに関するデータを入力する。入力されたデータに基づき、Amazon Pinpointへ通知送信をリクエストする。
5-1-5-1. 利用者通知_メッセージ通知機能
概要：
達成できる業務：
インタフェース例：
| インプット | 処理内容 | アウトプット |
|---|---|---|
| ・通知の宛先となる利用者データ ・連絡内容を含む通知データ | ・宛先となる利用者に対して、通知データを送信する | ・利用者に対する通知メール ・利用者のモバイル端末に対するSMSもしくはプッシュ通知 |
連携機能ブロック：
利用者通知_メッセージ通知機能（パターン1 SES利用）
ブロック実現例 （#メッセージキュー）
ブロック実現例 説明
[1]
[2]
[3]
※ Amazon SESをメール送信に利用する場合には、送信者評価に関するメトリクス(バウンス率や苦情率)の監視を実施することが推奨である。Amazon SESでは、バウンス率や苦情率のメトリクスが重視されており、こららの値が高過ぎる場合には、アカウントのレビューを行い、さらに、メール送信機能を一時停止する場合も有り得る。また、Amazon SESのVirtual Deliverability Managerを有効化すると、送信者評価に関するダッシュボードや、メール送信に関する推奨事項に関するアドバイザーが利用可能となる。
なお、Amazon SESをメール送信に利用する場合のベストプラクティスは下記のリンクから確認可能である。
https://docs.aws.amazon.com/ja_jp/ses/latest/dg/best-practices.htmlOpens in new tab
利用者通知_メッセージ通知機能（パターン2 Pinpoint利用）
ブロック実現例 （#メッセージキュー）
ブロック実現例 説明
[1]
[2]
[3]
5-1-5-2. 利用者通知_プッシュ通知機能
概要：
達成できる業務：
インタフェース例：
| インプット | 処理内容 | アウトプット |
|---|---|---|
| ・通知の宛先となる利用者データ ・連絡内容を含む通知データ | 宛先となる利用者に対して、通知データを送信する | 利用者のスマホアプリ（モバイル端末）に対するプッシュ通知 |
連携機能ブロック：
利用者通知_プッシュ通知機能
ブロック実現例 （#メッセージキュー）
ブロック実現例 説明
[1]
[2]
[3]
5-1-5-3. 利用者通知_アラート通知機能
概要：
達成できる業務：
インタフェース例：
| インプット | 処理内容 | アウトプット |
|---|---|---|
| ・通知の宛先となる利用者データ ・連絡内容を含む通知データ | ・宛先となる利用者に対して、通知データを送信する | ・利用者に対する通知メール ・利用者のモバイル端末に対するSMSもしくはプッシュ通知 |
| ・通知の宛先となる利用者のリスト | ・通知の宛先として登録 | ・なし |
連携機能ブロック：
利用者通知_アラート通知機能（パターン1 SES利用）
ブロック実現例 （#メッセージキュー）
ブロック実現例 説明
[1]
[2]
[3]
利用者通知_アラート通知機能（パターン2 Pinpoint利用）
ブロック実現例 （#メッセージキュー）
ブロック実現例 説明
[1]
[2]
[3]
利用者通知_アラート通知機能（パターン3 一斉送信）
ブロック実現例 （#メッセージキュー）
ブロック実現例 説明
[1]
[2]
[3]
[4]
5-1-6. コンテンツ管理
- 職員による登録、もしくはサーバにて生成されたWebページを利用者に提供する。
- 静的コンテンツを配信する。
- フロントエンドアプリが利用する機能
- コンテンツ管理_Webページ（動的コンテンツ）公開機能
- 利用者認証_ユーザ認証機能（国民向け）
- 利用者認証_ユーザ認証機能（企業ユーザ向け）
- 利用者認証_ユーザ認証機能（職員向け）
- 静的ファイル（HTML、JavaScript、CSS）をCloudFront及びS3で配信する。
- ファイルは高耐久なオブジェクトストレージであるS3に保管する。
- CloudFrontはCDNとしての機能を提供し、大量のリクエストにも低レイテンシーでの応答を実現する。
- WAF(※)によりインターネット経由で行われる様々な攻撃からコンテンツ管理_Webページ（静的コンテンツ）公開機能を保護する。
※WAFのルールグループについては非機能ブロック「セキュリティ_通信を介した攻撃への保護」を参照すること。 - 配信された静的コンテンツは他の機能とAPIを通じて連携する。
- 時刻指定でのWebサイト更新などをマネジメントコンソール外から行う要件がある場合は、Webコンテンツ管理（CMS）機能の利用が推奨されます。
- 本パターンは、特定のユーザへのコンテンツの限定公開を想定したものである。
- CloudFrontのアクセス制御の機能(署名付きURLまたは署名付きCookie)を利用し、認証されたユーザのみがコンテンツにアクセス可能とする。CloudFrontでは、アクセスされたパスのパターンに応じて設定(ビヘイビア)を指定することにより、特定のパスのみを限定公開とできる。
- 静的ファイル(HTML、JavaScript、CSS)をCloudFront及びS3で配信する。
- ファイルは高耐久なオブジェクトストレージであるS3に保管する。
- CloudFrontはCDNとしての機能を提供し、大量のリクエストにも低レイテンシーでの応答を実現する。
- また、WAFによりインターネット経由で行われる様々な攻撃から本機能を保護する。
- ユーザーは他の機能ブロックにおいてユーザ認証を行い、認証トークンを取得する。
- 静的コンテンツ公開用のWebアプリケーションはバックエンドのコンテナアプリケーションで動作させる。
- ELBにWAFを関連づけることにより、インターネット経由で行われる様々な攻撃からWebアプリケーションを保護する。
- Webアプリケーションのリクエストの認可は認証系の機能ブロックにより発行されるトークンを検証することによって行われる。
- リクエストヘッダーに含まれるトークンの有効性を検証する。
- トークンが有効な場合のみ、APIリクエストは受理される。
- コンテナアプリケーションにより、CloudFrontの署名付きURLまたは署名付きCookieを発行する。署名付きURLと署名付きCookieの一般的な使い分けは下記の通りである。
- ・署名付きURL: 単一のファイルのアクセス制限を行う場合、または、クライアントがCookieをサポートしない場合
- ・署名付きCookie: 複数のファイルのアクセス制限を行う場合、または、既存のURLを変更したくない場合
- 本パターンは、特定のユーザへのコンテンツの限定公開を想定したものである。
- CloudFrontへのリクエスト時に処理実行を行うLambda@Edgeの機能を利用し、認証されたユーザのみがコンテンツにアクセス可能とする。IDプロバイダとOpenID Connect等の連携方式によって連携することを想定している。
- IDプロバイダとして連携機能内のAmazon Cognitoまたは外部システムを想定している。
- 静的ファイル(HTML、JavaScript、CSS)をCloudFront及びS3で配信する。
- ファイルは高耐久なオブジェクトストレージであるS3に保管する。
- CloudFrontはCDNとしての機能を提供し、大量のリクエストにも低レイテンシーでの応答を実現する。
- また、WAFによりインターネット経由で行われる様々な攻撃から本機能を保護する。
- Lambda@Edgeを利用し、利用者からのリクエストに所定のアクセス権が含まれるかを検証する。アクセス権が含まれる場合には、静的コンテンツへのアクセスを許可する。
- アクセス権が含まれない場合には、IDプロバイダへ利用者をリダイレクトする。そして、IDプロバイダでの利用者のログイン結果を基にアクセス権を発行する。
- IDプロバイダでのログイン結果として、OpenID Connectの認可コードフローにおける認可コードなどが想定される。
- 発行したアクセス権を使用して、利用者が限定公開のコンテンツへアクセスする。
- CloudFrontをCDNとして利用し、大量のリクエストにも低レイテンシーでの応答を実現する。
- WAF(※)によりインターネット経由で行われる様々な攻撃からコンテンツ管理_Webページ（静的コンテンツ）公開機能を保護する。
※WAFのルールグループについては非機能ブロック「セキュリティ_通信を介した攻撃への保護」を参照すること。 - 静的ファイル(HTML、JavaScript、CSS)はSSR(Server Side Rendering)により生成し配信する。
- SSRの実行サーバーとしてサーバーレスなコンテナ実行環境であるECSを採用し、ELBによりコンテナ間の負荷分散を実現する。
- SSRサーバーは必要に応じて、他機能のAPIから動的コンテンツを取得しつつレンダリングを行う。
- 配信された静的コンテンツは他の機能とAPIを通じて連携する。
- 動的に生成されるWebページ（電子掲示板や個人情報表示、検索ツールなど）を利用者に提供する。
- 動的に生成されるWebページコンテンツ（電子掲示板や個人情報表示、検索ツールなど）を配信する。
- 他のコンテンツ管理_Webページ（動的コンテンツ）公開機能
- コンテンツ管理_Webページ（動的コンテンツ）公開機能
- UIを提供する機能
- コンテンツ管理_Webページ（静的コンテンツ）公開機能
- 認証機能
- 利用者認証_ユーザ認証機能（国民向け）
- 利用者認証_ユーザ認証機能（企業ユーザ向け）
- 利用者認証_ユーザ認証機能（職員向け）
- この機能は、他の機能により提供されるフロントエンドアプリからアクセスされることを想定する。
- ユーザーは他の機能ブロックにおいてユーザ認証を行い、認証トークンを取得する。
- Webアプリケーションは、フロントエンド、バックエンド分離の構成とし、バックエンド側はコンテナ上で動作させる。
- ELBにWAF(※)を関連づけることにより、インターネット経由で行われる様々な攻撃からWebアプリケーションを保護する。
※WAFのルールグループについては非機能ブロック「セキュリティ_通信を介した攻撃への保護」を参照すること。 - 取得した認証トークンをWebアプリケーションが検証し、認可されたリクエストをバックエンドアプリケーションが処理する。
- この処理ではAPIを通じてデータストレージへの更新や削除、その他の機能との連携を実施する。
- Webページで配信するコンテンツ（テキストや画像、ファイル）の管理を行う。
- Webサイトで配信するコンテンツの管理機能を提供する
- コンテンツを利用者（閲覧者）へ提供する
- 本機能はコンテンツ管理を行うヘッドレスCMS部分と、そこから取得した情報を表示するためのフロントエンド配信部から構成される。
- Webサイトの閲覧者は静的コンテンツをCDN+オブジェクトストレージから取得する。
- CloudFrontのCDNキャッシュ機能により高速な配信が可能である。
- フロントエンド開発者が変更を加える場合は、CodeCommit等コードレポジトリでの変更イベントをトリガーとし、ビルド及びデプロイプロセスを開始する。
- ビルド時には必要に応じてCMSからコンテンツを取得する。
- コンテンツの配信及び職員によるコンテンツの編集は外部のヘッドレスCMSサービスで行う。
- 本機能はコンテンツ管理を行うヘッドレスCMS部分と、そこから取得した情報を表示するためのフロントエンド配信部から構成される。
- Webサイトの閲覧者は静的コンテンツをコンテナアプリケーションから取得する。
- コンテナアプリケーションはヘッドレスCMSからコンテンツを取得しSSRを行う。
- フロントエンド開発者が変更を加える場合は、CodeCommit等コードレポジトリでの変更イベントをトリガーとし、ビルド及びデプロイプロセスを開始する。
- ビルド時には必要に応じてCMSからコンテンツを取得する。
- コンテンツの配信及び職員によるコンテンツの編集は外部のヘッドレスCMSサービスで行う。
- 本機能はコンテンツ管理を行うヘッドレスCMS部分と、そこから取得した情報を表示するためのフロントエンド配信部から構成される。
- ヘッドレスCMSはOSSでGitベースCMSに分類されるDecapCMSの利用を前提とする。
- また、本パターンは、小規模サイトでの利用を想定している。コンテンツのビルドに時間を要するSSGが前提となっており、また、コンテンツの保管先となるGitレポジトリ固有の制限(例. ファイルサイズの上限)を考慮する必要があるからである。
- Webサイトの閲覧者は静的コンテンツをCDN+オブジェクトストレージから取得する。
- CloudFrontのCDNキャッシュ機能により高速な配信が可能である。
- フロントエンド開発者はフロントエンドアプリコードの修正をコードレポジトリへプッシュする。
- この変更イベントをトリガーとし、ビルド及びデプロイプロセスを開始する。
- 職員によるコンテンツの編集はCDN+オブジェクトストレージから配信されるDecapCMSの管理者用ページから行う。コンテンツはコードレポジトリにて保管される。
- 職員によるコンテンツ更新や、フロントエンド開発者によるフロントエンドアプリの更新をトリガーとして、Next.jsやNuxt.jsによるSSGが実行される。
- SSG実行時にはDecapCMSがコードレポジトリからコンテンツを取得する。
5-1-6-1. コンテンツ管理_Webページ（静的コンテンツ）公開機能
概要：
達成できる業務：
インタフェース例：
| インプット | 処理内容 | アウトプット |
|---|---|---|
| ・ユーザーからのリクエスト | ・ユーザーのリクエストに応じてファイルを配信する | ・静的コンテンツ |
連携機能ブロック：
コンテンツ管理_Webページ（静的コンテンツ）公開機能 （パターン1 S3ホスト）
ブロック実現例 （#サーバレスフロントエンド）
ブロック実現例 説明
[1]
[2]
[注]
コンテンツ管理_Webページ（静的コンテンツ）公開機能 （パターン2 コンテンツの限定公開：署名付きURL or 署名付きCookie）
ブロック実現例 （#コンテナバックエンド #サーバレスフロントエンド）
ブロック実現例 説明
[1]
[2]
[3]
[4]
[5]
コンテンツ管理_Webページ（静的コンテンツ）公開機能 （パターン3 コンテンツの限定公開：IDプロバイダ連携）
ブロック実現例 （#サーバレスフロントエンド）
ブロック実現例 説明
[1]
[2]
コンテンツ管理_Webページ（静的コンテンツ）公開機能 （パターン4 SSR（サーバサイドレンダリング））
ブロック実現例 （#コンテナフロントエンド）
ブロック実現例 説明
[1]
[2]
[3]
[4]
5-1-6-2. コンテンツ管理_Webページ（動的コンテンツ）公開機能
概要：
達成できる業務：
インタフェース例：
| インプット | 処理内容 | アウトプット |
|---|---|---|
| ・リクエストとそのペイロード | ・リクエストに応じて、動的コンテンツを生成する | ・動的コンテンツ |
連携機能ブロック：
コンテンツ管理_Webページ（動的コンテンツ）公開機能
ブロック実現例 （#コンテナバックエンド）
ブロック実現例 説明
[1]
[2]
[3]
[4]
5-1-6-3. コンテンツ管理_Webコンテンツ管理（CMS）機能
概要：
達成できる業務：
インタフェース例：
| インプット | 処理内容 | アウトプット |
|---|---|---|
| ・利用者（閲覧者）からのコンテンツ取得リクエスト | ・リクエストに応じてデータを配信する | ・コンテンツ |
| ・職員（管理者）によるコンテンツの追加・更新・削除リクエスト | ・リクエストに応じてコンテンツを追加・更新・削除する | ・なし |
連携機能ブロック：
特になし
コンテンツ管理_Webコンテンツ管理（CMS）機能（パターン1 SaaS利用・CSR/SSG）
ブロック実現例
ブロック実現例 説明
[1]
[2]
[3]
[4]
[5]
コンテンツ管理_Webコンテンツ管理（CMS）機能（パターン2 SaaS利用・SSR）
ブロック実現例
ブロック実現例 説明
[1]
[2]
[3]
[4]
[5]
コンテンツ管理_Webコンテンツ管理（CMS）機能（パターン3 小規模サイト向け、OSSセルフホスティング SSG ）
ブロック実現例
ブロック実現例 説明
[1]
[2]
[3]
[4]
[5]
[6]
5-1-7. コミュニケーション
- 職員、もしくは利用システムと利用者とのコミュニケーションを目的にメール受領、メール配信を提供する。
- ユーザーからの入力に対し、Eメールにより応答する。
- UIを提供する機能
- コンテンツ管理_Webページ（静的コンテンツ）公開機能
- ユーザーがお問い合わせ内容を入力するフォームは静的コンテンツとして配信される。
- フォームの入力内容はAPI Gatewayで構築されたバックエンドAPIで処理される。
- APIの処理を担うLambda関数は、問い合わせ内容をメールとしてAmazon SESから管理者へ送信する。
- なお、バックアップや分析を目的として問い合わせ内容をストレージへ保管する場合には、Lambda関数を使用してS3へ保管する。
- 職員は受信したメールに対しての回答を個別に返信する。
- 職員、もしくは利用システムと利用者とのコミュニケーションを目的に音声ガイダンス、チャット機能を提供する。
- ユーザーからの入力に対し、電話、チャットにより応答する。
- UIを提供する機能
- コンテンツ管理_Webページ（静的コンテンツ）公開機能
- Amazon Connectによりクラウド上にコールセンター機能を構築し、利用者と職員の電話によるコミュニケーションを実装する。
- 自動音声ガイダンスによる案内もAmazon Connectの機能により実現する。
- なお、バックアップや分析を目的として電話によるコミュニケーションデータを保管する場合には、Amazon ConnectからS3へ保管する。
- Amazon Connectのチャット機能により、チャットベースでのコミュニケーションも実現する。
- チャットを行うためのユーザーインターフェースは別途静的コンテンツとして別機能から配信される。
- 職員、もしくは利用システムと利用者とのコミュニケーションを目的にチャットボットを提供する。
- ユーザーからの入力に対し、チャットボットが自動で応答する。
- UIを提供する機能
- コンテンツ管理_Webページ（静的コンテンツ）公開機能
- 本機能は他の機能が提供するフロントエンドアプリから利用されることを想定する。
- ユーザはCognitoからFederated User Identityの一時クレデンシャルを取得する。
- AWS SDK for JavascriptまたはAmplify Librariesを利用し、Amazon Lexのチャットボットへアクセスする。
- チャットボットは、あらかじめ定められたルールに則って回答をする。
- なお、バックアップや分析を目的としてチャットボットを利用した問い合わせ内容を保管する場合には、CloudWatch Logsへテキストログを保管する。
- 一部の質問に関しては、カスタム応答関数からAmazon Kendraへ検索クエリを発行し、S3に保管されているデータから検索を行った上で回答する。
- 職員と行政サービス利用者とのコミュニケーションの円滑化を目的にヘルプデスク支援を行う。
- 職員と行政サービス利用者とのコミュニケーションの円滑化を目的にヘルプデスク支援を行うため、問い合わせ管理やFAQ管理を行う機能を提供する。
- UIを提供する機能
- コンテンツ管理_Webページ（静的コンテンツ）公開機能
- 認証機能
- 利用者認証_ユーザ認証機能（国民向け）
- 利用者認証_ユーザ認証機能（職員向け）
- 通知機能
- 利用者通知_メッセージ通知機能
- 利用者通知_プッシュ通知機能
- ユーザがお問い合わせ内容を入力するフォームは静的コンテンツとして配信される。
- ユーザはログイン時にトークンを取得する。
- ユーザはAPI Gatewayにより提供されるREST APIを通じて問い合わせ内容を送信する。
- リクエストはAPI GatewayのLambda Authorizerによるトークン検証により認可される。
- ユーザから送信されたデータはLambda関数により入力内容のチェックの後、DocumentDBへと保管される。
- 連携機能を通じて新しい問い合わせが追加されたことを職員へ通知する。
- 職員が問い合わせ内容を確認するWebページは静的コンテンツとして配信される。
- 職員はログイン時にトークンを取得する。
- 職員API Gatewayにより提供されるREST APIを通じて問い合わせ内容を参照する。
- リクエストはAPI GatewayのLambda Authorizerによるトークン検証により認可される。
- 職員による問い合わせに対する返信やステータス更新はLambda関数により行われる。
- 必要な場合は連携機能を通じて利用者へ通知が行われる。
- 利用者は自身が送信した問い合わせ内容履歴や職員による返信の確認を行える。
5-1-7-1. コミュニケーション_問い合わせフォーム機能
概要：
達成できる業務：
インタフェース例：
| インプット | 処理内容 | アウトプット |
|---|---|---|
| ・お問い合わせフォームでの入力 | ・職員へ問い合わせ内容をEメールで連携する | ・職員によるEメールによる応答 |
連携機能ブロック：
コミュニケーション_問い合わせフォーム機能
ブロック実現例 （#サーバレスバックエンド）
ブロック実現例 説明
[1]
[2]
[3]
[4]
5-1-7-2. コミュニケーション_コールセンター/チャット機能
概要：
達成できる業務：
インタフェース例：
| インプット | 処理内容 | アウトプット |
|---|---|---|
| ・ユーザーからのチャット又は電話による入力 | ・職員へ問い合わせ内容を連携する | ・職員によるチャット又は電話による応答 |
連携機能ブロック：
コミュニケーション_コールセンター/チャット機能
ブロック実現例
ブロック実現例 説明
[1]
[2]
5-1-7-3. コミュニケーション_チャットボット機能
概要：
達成できる業務：
インタフェース例：
| インプット | 処理内容 | アウトプット |
|---|---|---|
| ・ユーザーからのチャット入力 | ・チャットボットによる自動応答生成 | ・チャットボットによる応答テキスト |
| ・Amazon Kendraが検索対象とするデータ | ・S3へのアップロード | ・なし |
| ・Amazon Kendraが検索対象とするデータの更新リクエスト | ・S3へのアップロード | ・なし |
| ・Amazon Kendraが検索対象とするデータの削除リクエスト | ・S3のデータの削除 | ・なし |
連携機能ブロック：
コミュニケーション_チャットボット機能
ブロック実現例
ブロック実現例 説明
[1]
[2]
[3]
[4]
5-1-7-4. コミュニケーション_ヘルプデスク支援機能
概要：
達成できる業務：
インタフェース例：
| インプット | 処理内容 | アウトプット |
|---|---|---|
| ・利用者による問い合わせ内容送信リクエスト | ・問い合わせ内容をDBへ保存 | ・なし |
| ・利用者による問い合わせ内容参照リクエスト | ・問い合わせ内容をDBからクエリする | ・問い合わせ内容 |
| ・職員による問い合わせ内容参照リクエスト | ・問い合わせ内容をDBからクエリする | ・問い合わせ内容 |
| ・職員による問い合わせ内容への返信およびステータス更新リクエスト | ・問い合わせへの返信内容やステータスをDBへ保存する | ・なし |
連携機能ブロック：
コミュニケーション_ヘルプデスク支援機能
ブロック実現例 （#サーバレスバックエンド）
ブロック実現例 説明
[1]
[2]
[3]
[4]
[5]
[6]
[7]
[8]
[9]
5-1-8. 外部連携
- 申請・届出の案件処理にあたって後続処理のために外部システムの機能（API）を呼び出す。
- 外部のAPIへインターネット経由またはGSS経由でリクエストを送る。
- 外部のSaaSへデータを連携する。
- 外部連携を必要とする機能
- 申請・届出_申請・届出機能
- 申請・届出_電子決裁機能
- 本機能は他の機能ブロックにおいて何等かの処理を実行する上で、外部システムへリクエストを送信する必要がある場合を想定する。
- 外部システム連携のトリガーはAPI Gateway、StepFunctions、またはS3等のサービスによるイベントが想定される。
- 他の機能ブロックによりLambdaがトリガーされ、他システムへリクエストが送信される。
- 本機能は、WebAPIによる外部システムとの連携を前提としており、SFTPによるファイル連携や、メッセージキューイング（MQ）による連携などにおいては、外部システムに対応したクライアントライブラリがLambda上で動作する場合には本機能と同様の構成により連携を行うことができる。
- また、SFTPによるファイル連携に関しては、Transfer FamilyのSFTPコネクタを利用して、外部システムのFTPサーバとS3の間でファイルの連携を行う構成も可能である。
- 本機能は他の機能ブロックにおいて何等かの処理を実行する上で、外部システムへリクエストを送信する必要がある場合を想定する。
- 外部システム連携のトリガーはAPI Gateway、StepFunctions、またはS3等のサービスによるイベントが想定される。
- 他の機能ブロックによりLambdaがトリガーされ、他システムへリクエストが送信される。
- 本機能は、WebAPIによる外部システムとの連携を前提としている。SFTPによるファイル連携や、メッセージキューイング（MQ）による連携などにおいては、外部システムに対応したクライアントライブラリがLambda上で動作する場合には本機能と同様の構成により連携を行うことができる。
- また、SFTPによるファイル連携に関しては、Transfer FamilyのSFTPコネクタを利用して、外部システムのFTPサーバとS3の間でファイルの連携を行う構成も可能である。
- 本機能は他の機能ブロックにおいて何等かの処理を実行する上で、外部システムへリクエストを送信する必要がある場合を想定する。
- 外部システムへ連携するデータのソースはS3などが想定される（連携先SaaSにより対応するデータソースが異なる）。
- AWS AppFlowを利用しデータをSaaSへ連携する。
- Amazon AppFlow は、Salesforce SAP OData、SnowflakeなどのSaaSアプリケーションとAWSのサービスとの間で、コードを記述することなくデータを転送できるサービスである。
- 外部システムからの処理を受け付けるための機能（API）を公開する。
- 外部システムへ動的コンテンツを配信する
- クライアントシステムを認証する機能
- 外部連携_システム間認証機能
- APIを提供する機能
- コンテンツ管理_Webページ（動的コンテンツ）公開機能
- 外部システムは外部連携_システム間認証機能により認証が行われトークンが発行される。
- クライアントシステムは動的APIを提供する機能のAPI Gatewayへリクエストを送信する。
- API Gatewayは受信したリクエストに含まれるトークンを検証することにより、リクエストを認可する。
- 認可された場合リクエストはLambda関数によって処理される。
- API Gatewayは過剰なリクエストを受信した場合、使用量プランによりスロットリングを行う。
5-1-8-1. 外部連携_申請処理連携機能
概要：
達成できる業務：
インタフェース例：
| インプット | 処理内容 | アウトプット |
|---|---|---|
| ・外部APIリクエストのペイロードとなるデータ | ・外部へリクエストを送信する。 | ・外部APIからのレスポンス |
| ・外部SaaSへ連携するためのデータ | ・外部SaaSへデータを連携する。 | ・外部SaaSからのレスポンス |
連携機能ブロック：
外部連携_申請処理連携機能（パターン1 通常）
ブロック実現例
ブロック実現例 説明
[1]
[2]
外部連携_申請処理連携機能（パターン2 GSS経由の場合）
ブロック実現例
ブロック実現例 説明
[1]
[2]
外部連携_申請処理連携機能（パターン3 SaaS連携）
ブロック実現例
ブロック実現例 説明
[1]
[2]
補足：
本機能ブロックを利用する際には、Amazon AppFlowのサポート状況を事前に確認することが推奨される。連携先となるSaaSそのものに対するサポートがあるか、また、SaaSの中でも連携したいデータに対するサポートがあるか、どのタイプのデータ転送トリガー（オンデマンド、スケジュール、イベント）がサポートされているか、等の確認を行うことが推奨される。
5-1-8-2. 外部連携_外部連携機能（API公開）
概要：
達成できる業務：
インタフェース例：
| インプット | 処理内容 | アウトプット |
|---|---|---|
| ・クライアントシステムからのリクエスト | ・リクエストに応じてデータを配信する。 | ・動的コンテンツ |
連携機能ブロック：
外部連携_外部連携機能（API公開）
ブロック実現例 （#サーバレスバックエンド）
ブロック実現例 説明
[1]
[2]
[3]
5-1-9. 書類出力
- 郵送宛名ラベルや送付書類などの業務関連書類を出力する。
- アップロードされたファイルを印刷のために通知・送付する。
- 郵送書類の内容を生成する機能
- 申請・届出_ステータス管理機能
- 申請・届出_電子決裁機能
- 本機能は他の機能が出力するデータをもとに郵送書類を作成する機能である。
- なお、作成する郵送書類は郵送ラベル等の簡易的かつ一般的なフォーマットであること前提としている。
- 他機能はLambdaを起動することで、郵送書類の生成を開始する。
- Lambda関数は起動イベントJSON内に含まれるペイロードデータをもとに必要な書類をPDFなどの形式で出力する。
- 書類はS3へアップロードされる。
- S3のアップロードイベントを元に署名付きURLがLambdaで発行される。
- LambdaからSNSの通知トピック経由で利用者へEメールが送信される。
- 利用者はS3からファイルをダウンロードし、印刷する。
- 本機能は他の機能が出力するデータをもとに郵送書類を作成する機能である。
- なお、作成する郵送書類は郵送ラベル等の簡易的かつ一般的なフォーマットであること前提としている。
- 他機能はLambdaを起動することで、郵送書類の生成を開始する。
- Lambda関数は起動イベントJSON内に含まれるペイロードデータをもとに必要な書類をPDFなどの形式で出力する。
- 書類はS3へアップロードされる。
- S3のアップロードイベントを元にSNSの通知トピック経由で利用者へEメールが送信される。
- 利用者はS3からファイルをダウンロードし、印刷する。
- 本機能は他の機能が出力するデータをもとに郵送書類を作成する機能である。
- なお、作成する郵送書類は郵送ラベル等の簡易的かつ一般的なフォーマットであること前提としている。
- 他機能はLambdaを起動することで、郵送書類の生成を開始する。
- Lambda関数は起動イベントJSON内に含まれるペイロードデータをもとに必要な書類をPDFなどの形式で出力する。
- 書類はS3へアップロードされる。
- S3のアップロードイベントを元にLambdaが起動し、SES(※)を利用して印刷業者へEメールを送信する。
※Amazon SESのメール送信については、アクセスキーが不要なIAMロールを使ったSES APIの利用を推奨。 - 本機能は他の機能が出力するデータをもとに郵送書類を作成する機能である。
- なお、作成する郵送書類は郵送ラベル等の簡易的かつ一般的なフォーマットであること前提としている。
- 他機能はLambdaを起動することで、郵送書類の生成を開始する。
- Lambda関数は起動イベントJSON内に含まれるペイロードデータをもとに必要な書類をPDFなどの形式で出力する。
- 書類はS3へアップロードされる。
- 署名付きURLがLambdaで発行される。LambdaからSNSの通知トピック経由で利用者へEメールが送信される。
- 利用者はS3からファイルをダウンロードし、印刷する。
- S3のアップロードイベントを元にLambdaが起動し、SES(※)を利用して印刷業者へEメールを送信する。
※Amazon SESのメール送信については、アクセスキーが不要なIAMロールを使ったSES APIの利用を推奨。 - 本機能は他の機能が出力するデータをもとに郵送書類を作成する機能である。
- なお、作成する郵送書類は郵送ラベル等の簡易的かつ一般的なフォーマットであること前提としている。
- 他機能はLambdaを起動することで、郵送書類の生成を開始する。
- Lambda関数は起動イベントJSON内に含まれるペイロードデータをもとに必要な書類をPDFなどの形式で出力する。
- 書類はS3へアップロードされる。
- S3のアップロードイベントを元にSNSの通知トピック経由で利用者へEメールが送信される。
- 利用者はマネジメントコンソールにアクセスし、S3からファイルをダウンロードし、印刷する。
- S3のアップロードイベントを元にLambdaが起動し、SES(※)を利用して印刷業者へEメールを送信する。
※Amazon SESのメール送信については、アクセスキーが不要なIAMロールを使ったSES APIの利用を推奨。 - 法令により定められた帳票（国民向け）の作成を行う。
- 届出・申請の結果などを法令で定められた形式で帳票として作成する業務
- 帳票の元データを出力
- 申請・届出_申請・届出機能
- 審査・承認_審査・承認機能
- 帳票を保管
- 申請・届出_公文書ダウンロード機能
- 申請・届出_公文書公開機能
- 帳票を外部システムに連携
- 外部連携_申請処理連携機能
- 申請・届出_申請・届出機能等の他の機能ブロックが、帳票作成のリクエストを送信する。
- 帳票作成は、疎結合な非同期処理とし、Amazon SQSをメッセージキューとして利用する。
- メッセージキュー（Amazon SQS）へ通知送信のリクエストが送信されたことを契機として、AWS Lambdaが自動的に起動する。
- AWS Lambdaはプログラムの実行環境をサーバレスで提供するものであり、帳票作成処理の実行環境を容易に構築可能である。
- 帳票のファイル形式としてPDFを想定するが、PDFの作成機能はマネージドサービスとして提供されていない。
- したがって、PDFの作成に必要なライブラリの導入が必要である。
- ライブラリの仕様によっては、AWS Lambdaではなく、コンテナイメージを実行可能なAmazon ECSも選択肢として検討できる。
- 作成した帳票は、他の機能ブロック内に存在するAmazon S3をストレージとして保管する。
- 作成した帳票を他システムに連携する場合には、外部連携機能を使用する。
- 法令により定められた帳票（システム利用府省庁向け）の作成を行う。
- 届出・申請の結果などを法令で定められた形式で帳票として作成する業務
- 帳票の元データを出力
- 申請・届出_申請・届出機能
- 審査・承認_審査・承認機能
- 帳票を保管
- 申請・届出_公文書ダウンロード機能
- 申請・届出_公文書公開機能
- 帳票を外部システムに連携
- 外部連携_申請処理連携機能
- 申請・届出_申請・届出機能等の他の機能ブロックが、帳票作成のリクエストを送信する。
- 帳票作成は、疎結合な非同期処理とし、Amazon SQSをメッセージキューとして利用する。
- メッセージキュー（Amazon SQS）へ通知送信のリクエストが送信されたことを契機として、AWS Lambdaが自動的に起動する。
- AWS Lambdaはプログラムの実行環境をサーバレスで提供するものであり、帳票作成処理の実行環境を容易に構築可能である。
- 帳票のファイル形式としてPDFを想定するが、PDFの作成機能はマネージドサービスとして提供されていない。
- したがって、PDFの作成に必要なライブラリの導入が必要である。
- ライブラリの仕様によっては、AWS Lambdaではなく、コンテナイメージを実行可能なAmazon ECSも選択肢として検討できる。
- 作成した帳票は、他の機能ブロック内に存在するAmazon S3をストレージとして保管する。
- 作成した帳票を他システムに連携する場合には、外部連携機能を使用する。
5-1-9-1. 書類出力_書類出力機能
概要：
達成できる業務：
インタフェース例：
| インプット | 処理内容 | アウトプット |
|---|---|---|
| ・郵送書類に記載すべき内容データ | ・郵送書類をファイル（PDF等）として書き出す ・アップロードイベントを元に通知メールを生成・送信する | ・郵送書類ファイル（PDF等） ・署名付きURL ・通知Eメール |
連携機能ブロック：
書類出力_書類出力機能 （パターン1 署名付きURLからのダウンロード）
ブロック実現例 （#サーバレスイベント処理）
ブロック実現例 説明
[1]
[2]
[3]
[4]
書類出力_書類出力機能 （パターン2 S3コンソールからのダウンロード）
ブロック実現例 （#サーバレスイベント処理）
ブロック実現例 説明
[1]
[2]
[3]
書類出力_書類出力機能 （パターン3 印刷会社等外部へのファイル送付）
ブロック実現例 （#サーバレスイベント処理）
ブロック実現例 説明
[1]
[2]
[3]
書類出力_書類出力機能 （パターン4 印刷会社等外部への一部ファイル送付、署名付きURLからのダウンロード）
ブロック実現例 （#サーバレスイベント処理 #ストレージ直接アクセス）
ブロック実現例 説明
[1]
[2]
[3]
[4]
[5]
書類出力_書類出力機能 （パターン5 印刷会社等外部への一部ファイル送付、S3コンソールからのダウンロード）
ブロック実現例 （#サーバレスイベント処理）
ブロック実現例 説明
[1]
[2]
[3]
[4]
5-1-9-2. 書類出力_法定帳票作成機能（外部）
概要：
達成できる業務：
インタフェース例：
| インプット | 処理内容 | アウトプット |
|---|---|---|
| ・帳票の元データ（届出・申請の結果など） ・帳票の形式データ | ・帳票の形式にしたがって、元データを含む帳票をPDF形式で作成。 | ・法定帳票（PDF形式） |
連携機能ブロック：
書類出力_法定帳票作成機能（外部）
ブロック実現例 （#メッセージキュー）
ブロック実現例 説明
[1]
[2]
[3]
[4]
5-1-9-3. 書類出力_法定帳票作成機能（内部）
概要：
達成できる業務：
インタフェース例：
| インプット | 処理内容 | アウトプット |
|---|---|---|
| ・帳票の元データ（届出・申請の結果など） ・帳票の形式データ | ・帳票の形式にしたがって、元データを含む帳票をPDF形式で作成。 | ・法定帳票（PDF形式） |
連携機能ブロック：
書類出力_法定帳票作成機能（内部）
ブロック実現例 （#メッセージキュー）
ブロック実現例 説明
[1]
[2]
[3]
[4]
5-1-10. スマホアプリ連携
- 行政機関より公開されたスマートフォンアプリとの連携を行う
- スマホアプリのユーザ認証、動的コンテンツの配信、及びプッシュ通知の送信を行う。
- 動的コンテンツを提供する機能
- コンテンツ管理_Webページ（動的コンテンツ）公開機能
- 認証機能
- 利用者認証_ユーザ認証機能（国民向け）
- 利用者認証_ユーザ認証機能（企業ユーザ向け）
- 利用者認証_ユーザ認証機能（職員向け）
- 通知の送信をリクエストする機能
- 申請・届出_申請・届出機能
- 審査・承認_審査・承認機能
- 本機能ではスマートフォンアプリは外部のアプリストアから配信されている前提とする。アプリを公開するためには、各アプリストアへの登録作業が必要となる。
- ユーザーは他の認証系機能ブロックにおいてユーザ認証を行い、認証トークンを取得する。
- 動的コンテンツへは取得した認証トークンを使ってアクセスする。
- オフライン時のユーザ操作により生成されたデータはスマートフォン端末のローカルストレージに保管される。
- スマートフォンがオンラインに復帰すると、ローカルストレージに保管されていたデータはGraphQLを通じてAmazon DynamoDB内のデータと同期される。
- 認証はAmplify Auth APIを通じてCognitoを使って行われる。
- プッシュ通知は利用者通知_プッシュ通知機能により送信される。
5-1-10-1. スマホアプリ連携_スマホアプリ連携機能
概要：
達成できる業務：
インタフェース例：
| インプット | 処理内容 | アウトプット |
|---|---|---|
| ・ユーザ認証リクエスト | ・ユーザ名やパスワードを照合し、認証トークンを生成する | ・認証トークン |
| ・動的コンテンツリクエスト | ・動的コンテンツを生成する | ・動的コンテンツ（JSONデータ） |
| ・審査結果の参照リクエスト | ・リクエストに応じてデータをクエリする | ・審査結果 |
| ・審査結果の更新リクエスト | ・リクエストに応じてデータを更新する | ・なし |
| ・審査結果の削除リクエスト | ・リクエストに応じてデータを削除する | ・なし |
連携機能ブロック：
スマホアプリ連携_スマホアプリ連携機能 （パターン1 オンライン連携）
ブロック実現例
ブロック実現例 説明
[1]
[2]
[3]
スマホアプリ連携_スマホアプリ連携機能 （パターン2 オフライン対応アプリ連携）
ブロック実現例
ブロック実現例 説明
[1]
[2]
[3]
[4]
5-2. 非機能ブロック
5-2-1. 利用者認証
- 行政サービスの利用にあたり国民固有の識別情報を用いて認証を行う。
- 利用者本人であることの確認を行う業務
- 利用者の情報を管理する業務
- 認証前のトップ画面を表示
- コンテンツ管理_Webページ（静的コンテンツ）公開機能
- 利用者の認証を要する機能
- 申請・届出_申請・届出機能
- 申請・届出_公文書ダウンロード機能 など
- 公的個人認証サービスと連携し、マイナンバーカードに搭載された電子証明書によって利用者の認証を行う。利用者は、スマホ等の端末で電子証明書に設定したPIN/パスワードを入力し、マイナンバーカードの読み取りを行う。
（注）公的個人認証サービスに関する技術情報（インタフェース仕様、連携のための手続きや制約事項等）は、別途確認する必要がある。
また、アプリケーションのトークン発行に関するAmazon Cognitoの構成はあくまで例であり、実現性を保証するものではない。公的個人認証サービスに関する技術情報や利用システムの要件に応じて構成を検討する必要がある。 - Amazon Cognitoのユーザプールの機能を使用し、公的個人認証サービスによって認証されたユーザに対するトークンを発行する。
- ユーザ情報を管理するためのWebAPIはAPI Gatewayにより構築される。API GatewayはAmazon CognitoをWebAPIの呼び出し可否の判断に使用するオーソライザーとして連携が可能である。Amazon Cognitoをオーソライザーとして設定することで、トークンの有効性確認の処理をAPI Gatewayに任せることができる。
- またWAF(※)によりインターネット経由で行われる様々な攻撃からAPIを保護する。
※WAFのルールグループについては非機能ブロック「セキュリティ_通信を介した攻撃への保護」を参照すること。 - Amazon DocumentDBに格納されたユーザ情報に対して、AWS Lambdaから新規作成や更新等の管理を行う。
- ID管理や外部のIDブロバイダとの連携をOSSを用いて実現する。
- OSSは、認証に関する要件に応じて選択するものとする。例えば、OpenID ConnectのOPの機能を実現するミドルウェアや、シンプルなIDとパスワードによる認証を実現するライブラリなどから、要件に応じて選択する。
- ミドルウェアやライブラリの利用に関しての制約が一般的には少ないコンテナ（Amaon ECS） に加え、AWS Lambdaによるサーバレス構成も検討できる。
- 外部のソーシャルIDプロバイダと連携してシステムへのログインを行う。
- 標準規格であるOpenID Connect及びSAML2.0に対応した外部サービスとの連携を想定。
- OSSで実現するID管理や外部のIDブロバイダとの連携では、ユーザ情報の保管先としてマネージドなデータベースを第一の選択肢として利用する。
- 利用するOSSがサポートするデータベースに準拠し、データベースを選択する。
- 利用するOSSがPostgreSQLまたはMySQLをサポートする場合は、Amazon Auroraが利用できる。
- ID管理機能が発行したトークンによるアクセス制御を行い、他のWebAPIを提供する機能ブロックへアクセスする。
- トークンの検証は、Amazon API GatewayのLambda Authorizerの機能を用い、サーバレスで実現する方法が考えられる。
- 外部のソーシャルIDプロバイダと連携してシステムへのログインを行う。
- Amazon Cognitoは、Facebook, Google, Amazon, Appleの4つのサービスに加え、OpenID Connect及びSAML2.0に対応した外部サービスと連携可能
- Amazon Cognitoのユーザプールの機能を使用し、ソーシャルIDプロバイダとの連携（フェデレーション）を実行する。
- ユーザ情報を管理するためのWebAPIはAPI Gatewayにより構築される。
- API GatewayはAmazon CognitoをWebAPIの呼び出し可否の判断に使用するオーソライザーとして連携が可能である。
- Amazon Cognitoをオーソライザとして設定することで、トークンの有効性確認の処理をAPI Gatewayに任せることができる。
- WAF(※)によりインターネット経由で行われる様々な攻撃からAPIを保護する。
※WAFのルールグループについては非機能ブロック「セキュリティ_通信を介した攻撃への保護」を参照すること。 - Amazon DocumentDBに格納されたユーザ情報に対して、AWS Lambdaから新規作成や更新等の管理を行う
- Amazon Cognitoが発行したトークンによるアクセス制御を行い、他のWebAPIを提供する機能ブロックへアクセスする。
- トークンの検証は、Amazon API GatewayのLambda Authorizerの機能を用い、サーバレスで実現する方法が考えられる。
- Amazon Cognitoでは、リクエストレートクォータとして、単位時間あたりのAPI呼び出しに上限が設定されている。リクエストレートクォータを上回る負荷が想定される場合には、Amazon Cognitoではなく、Amazon ECSを利用してコンテナ上で認証認可サーバを独自に構築する方法や、認証認可サーバの機能を提供する外部サービスの利用などの代替案を検討する必要がある
- Amazon Cognitoのユーザプールを利用して、利用者のIDとパスワードを管理する。
- 外部のID管理との連携が不要な場合、Amazon Cognitoを利用してのIDとパスワードの管理が可能である。
- ユーザ情報を管理するためのWebAPIはAPI Gatewayにより構築される。
- API GatewayはAmazon CognitoをWebAPIの呼び出し可否の判断に使用するオーソライザーとして連携が可能である。
- Amazon Cognitoをオーソライザとして設定することで、トークンの有効性確認の処理をAPI Gatewayに任せることができる。
- WAF(※)によりインターネット経由で行われる様々な攻撃からAPIを保護する。
※WAFのルールグループについては非機能ブロック「セキュリティ_通信を介した攻撃への保護」を参照すること。 - Amazon DocumentDBに格納されたユーザ情報に対して、AWS Lambdaから新規作成や更新等の管理を行う
- Amazon Cognitoが発行したトークンによるアクセス制御を行い、他のWebAPIを提供する機能ブロックへアクセスする。
- トークンの検証は、Amazon API GatewayのLambda Authorizerの機能を用い、サーバレスで実現する方法が考えられる。
- Amazon Cognitoでは、リクエストレートクォータとして、単位時間あたりのAPI呼び出しに上限が設定されている。リクエストレートクォータを上回る負荷が想定される場合には、Amazon Cognitoではなく、Amazon ECSを利用してコンテナ上で認証認可サーバを独自に構築する方法や、認証認可サーバの機能を提供する外部サービスの利用などの代替案を検討する必要がある
- Amazon Cognitoのユーザプールを利用して、ユーザのログインを行う。
- ユーザのログインは、外部のIDプロバイダとの連携と、Congnitoのユーザプールによるログインの両方が有り得る。
- Amazon Cognitoのアイデンティティプールを利用して、AWSリソースへの直接アクセスが可能なAWS一時認証情報を発行する。
- AWS一時認証情報は、事前に設定したIAM Roleの権限をもとに発行される。
- Amazon Cognitoのアイデンティティプールが発行したAWS一時認証情報を使用して、連携機能が持つAWSリソースへのアクセスを行う。例えば、Amazon S3からファイルをダウンロードすることなどが挙げられる。
- AWSリソースとはAWS上に作成された操作可能なエンティティを指す。AWSリソースへの直接アクセスとして、Amazon S3へのファイルのアップロードや、Amazon DynamoDBからのデータの取得などが挙げられる
- 行政サービスの利用にあたり企業ユーザ固有の識別情報を用いて認証を行う。
- 利用者本人であることの確認を行う業務
- 利用者の情報を管理する業務
- 認証前のトップ画面を表示
- コンテンツ管理_Webページ（静的コンテンツ）公開機能
- 利用者の認証を要する機能
- 申請・届出_申請・届出機能
- 申請・届出_公文書ダウンロード機能 など
- ユーザの認証ではGビズIDとの連携を行う。
- GビズIDとは、標準的な認証の仕様であるOpenID Connectのフローに従い、ユーザの認証を行う。
- 本機能ブロックでは、多要素認証を行う例を示しているが、IDとパスワードによる単要素での認証が可能なユーザの種類(gBizIDエントリー)もGビズIDには存在する。
- なお、GビズID発行について、個人事業主向けにはすでにオンライン発行可能となっている。また、法人代表者向けには令和5年度末にオンライン化が予定されている。
- Amazon Cognitoのユーザプールの機能を使用し、gBizIDとの連携（フェデレーション）を実行する。
- ユーザ情報を管理するためのWebAPIはAPI Gatewayにより構築される。
- API GatewayはAmazon CognitoをWebAPIの呼び出し可否の判断に使用するオーソライザーとして連携が可能である。
- Amazon Cognitoをオーソライザーとして設定することで、トークンの有効性確認の処理をAPI Gatewayに任せることができる。
- WAF(※)によりインターネット経由で行われる様々な攻撃からAPIを保護する。
※WAFのルールグループについては非機能ブロック「セキュリティ_通信を介した攻撃への保護」を参照すること。 - Amazon DocumentDBに格納されたユーザ情報に対して、AWS Lambdaから新規作成や更新等の管理を行う
- Amazon Cognitoが発行したトークンによるアクセス制御を行い、他のWebAPIを提供する機能ブロックへアクセスする。
- トークンの検証は、Amazon API GatewayのLambda Authorizerの機能を用い、サーバレスで実現する方法が考えられる。
- gBizID システム連携ガイド（行政サービス向け）: https://gbiz-id.go.jp/top/system_guide/system_guide.htmlOpens in new tab
- Amazon Cognitoでは、リクエストレートクォータとして、単位時間あたりのAPI呼び出しに上限が設定されている。リクエストレートクォータを上回る負荷が想定される場合には、Amazon Cognitoではなく、Amazon ECSを利用してコンテナ上で認証認可サーバを独自に構築する方法や、認証認可サーバの機能を提供する外部サービスの利用などの代替案を検討する必要がある。
- Amazon Cognitoのユーザプールを利用して、利用者のIDとパスワードを管理する。
- 外部のID管理との連携が不要な場合、Amazon Cognitoを利用してのIDとパスワードの管理が可能である。
- ユーザ情報を管理するためのWebAPIはAPI Gatewayにより構築される。
- API GatewayはAmazon CognitoをWebAPIの呼び出し可否の判断に使用するオーソライザーとして連携が可能である。
- Amazon Cognitoをオーソライザとして設定することで、トークンの有効性確認の処理をAPI Gatewayに任せることができる。
- WAF(※)によりインターネット経由で行われる様々な攻撃からAPIを保護する。
※WAFのルールグループについては非機能ブロック「セキュリティ_通信を介した攻撃への保護」を参照すること。 - Amazon DocumentDBに格納されたユーザ情報に対して、AWS Lambdaから新規作成や更新等の管理を行う
- Amazon Cognitoが発行したトークンによるアクセス制御を行い、他のWebAPIを提供する機能ブロックへアクセスする。
- トークンの検証は、Amazon API GatewayのLambda Authorizerの機能を用い、サーバレスで実現する方法が考えられる。
- Amazon Cognitoでは、リクエストレートクォータとして、単位時間あたりのAPI呼び出しに上限が設定されている。リクエストレートクォータを上回る負荷が想定される場合には、Amazon Cognitoではなく、Amazon ECSを利用してコンテナ上で認証認可サーバを独自に構築する方法や、認証認可サーバの機能を提供する外部サービスの利用などの代替案を検討する必要がある
- 行政サービスの利用にあたり職員固有の識別情報を用いて認証を行う。
- 利用者本人であることの確認を行う業務
- 利用者の情報を管理する業務
- 認証前のトップ画面を表示
- コンテンツ管理_Webページ（静的コンテンツ）公開機能
- 利用者の認証を要する機能
- 申請・届出_申請・届出機能
- 申請・届出_公文書ダウンロード機能 など
- ユーザの認証では外部のID管理システムとの連携を行う。
- 標準的な認証の仕様であるOpenID Connectのフローに従い、ユーザの認証を行う。
- Amazon Cognitoのユーザプールの機能を使用し、外部IDプロバイダとの連携（フェデレーション）を実行する。
- ユーザ情報を管理するためのWebAPIはAPI Gatewayにより構築される。
- API GatewayはAmazon CognitoをWebAPIの呼び出し可否の判断に使用するオーソライザーとして連携が可能である。
- Amazon Cognitoをオーソライザーとして設定することで、トークンの有効性確認の処理をAPI Gatewayに任せることができる。
- WAF(※)によりインターネット経由で行われる様々な攻撃からAPIを保護する。
※WAFのルールグループについては非機能ブロック「セキュリティ_通信を介した攻撃への保護」を参照すること。 - Amazon DocumentDBに格納されたユーザ情報に対して、AWS Lambdaから新規作成や更新等の管理を行う。
- Amazon Cognitoが発行したトークンによるアクセス制御を行い、他のWebAPIを提供する機能ブロックへアクセスする。
- トークンの検証は、Amazon API GatewayのLambda Authorizerの機能を用い、サーバレスで実現する方法が考えられる。
- Amazon Cognitoでは、リクエストレートクォータとして、単位時間あたりのAPI呼び出しに上限が設定されている。リクエストレートクォータを上回る負荷が想定される場合には、Amazon Cognitoではなく、Amazon ECSを利用してコンテナ上で認証認可サーバを独自に構築する方法や、認証認可サーバの機能を提供する外部サービスの利用などの代替案を検討する必要がある。
- Amazon Cognitoのユーザプールを利用して、利用者のIDとパスワードを管理する。
- 外部のID管理との連携が不要な場合、Amazon Cognitoを利用してのIDとパスワードの管理が可能である。
- ユーザ情報を管理するためのWebAPIはAPI Gatewayにより構築される。
- API GatewayはAmazon CognitoをWebAPIの呼び出し可否の判断に使用するオーソライザーとして連携が可能である。
- Amazon Cognitoをオーソライザーとして設定することで、トークンの有効性確認の処理をAPI Gatewayに任せることができる。
- WAF(※)によりインターネット経由で行われる様々な攻撃からAPIを保護する。
※WAFのルールグループについては非機能ブロック「セキュリティ_通信を介した攻撃への保護」を参照すること。 - Amazon DocumentDBに格納されたユーザ情報に対して、AWS Lambdaから新規作成や更新等の管理を行う。
- Amazon Cognitoが発行したトークンによるアクセス制御を行い、他のWebAPIを提供する機能ブロックへアクセスする。
- トークンの検証は、Amazon API GatewayのLambda Authorizerの機能を用い、サーバレスで実現する方法が考えられる。
- Amazon Cognitoでは、リクエストレートクォータとして、単位時間あたりのAPI呼び出しに上限が設定されている。リクエストレートクォータを上回る負荷が想定される場合には、Amazon Cognitoではなく、Amazon ECSを利用してコンテナ上で認証認可サーバを独自に構築する方法や、認証認可サーバの機能を提供する外部サービスの利用などの代替案を検討する必要がある。
- 職員情報を管理するActive DirectoryとSAML 2.0で連携してシステムへのログインを行う。
- Active DirectoryにはAWS Managed Microsoft ADを利用し、SAMLのIdPを構築するためのADFSをAmazon EC2を利用して構築する。
- Amazon Cognitoのユーザプールの機能を使用し、SAML2.0の利用したADFSとの連携（フェデレーション）を実行する。
- ユーザ情報を管理するためのWebAPIはAPI Gatewayにより構築される。
- API GatewayはAmazon CognitoをWebAPIの呼び出し可否の判断に使用するオーソライザーとして連携が可能である。
- Amazon Cognitoをオーソライザとして設定することで、トークンの有効性確認の処理をAPI Gatewayに任せることができる。
- またWAF(※)によりインターネット経由で行われる様々な攻撃からAPIを保護する。
※WAFのルールグループについては非機能ブロック「セキュリティ_通信を介した攻撃への保護」を参照すること。 - Amazon DocumentDBに格納されたユーザ情報に対して、AWS Lambdaから新規作成や更新等の管理を行う。
- Amazon Cognitoが発行したトークンによるアクセス制御を行い、他のWebAPIを提供する機能ブロックへアクセスする。
- トークンの検証は、Amazon API GatewayのLambda Authorizerの機能を用い、サーバレスで実現する方法が考えられる。
- Amazon Cognitoでは、リクエストレートクォータとして、単位時間あたりのAPI呼び出しに上限が設定されている。リクエストレートクォータを上回る負荷が想定される場合には、Amazon Cognitoではなく、Amazon ECSを利用してコンテナ上で認証認可サーバを独自に構築する方法や、認証認可サーバの機能を提供する外部サービスの利用などの代替案を検討する必要がある
5-2-1-1. 利用者認証_ユーザ認証機能（国民向け）
概要：
達成できる業務：
インタフェース例：
| インプット | 処理内容 | アウトプット |
|---|---|---|
| ・外部のIDプロバイダが発行した認証結果 | ・認証結果が正当なものであることを検証する。（認証結果として、OpenID Connectにおける認可コードや、SAML2.0におけるアサーションを想定） | ・認証済みであることを示すトークンを返却 |
| ・利用者が設定したIDとパスワード | ・登録済みのIDとパスワードと一致するかを確認する | ・認証済みであることを示すトークンを返却 |
| ・ユーザ情報の参照リクエエスト | ・登録済みのユーザ情報を取得する | ・ユーザ情報を返却 |
| ・ユーザ情報の更新データ | ・更新データを受信し、登録済みのユーザ情報を更新する | ・なし |
| ・ユーザ情報の削除リクエスト | ・削除リクエストを受信し、登録済みのユーザ情報を削除する | ・なし |
| ・利用者認証_ユーザ認証機能（国民向け）が発行したトークン | ・トークンが正当なものであることを検証する | ・なし |
連携機能ブロック：
利用者認証_ユーザ認証機能（国民向け）（パターン1 公的個人認証サービスを利用）
ブロック実現例 （#サーバレスバックエンド）
ブロック実現例 説明
[1]
[2]
[3]
[4]
利用者認証_ユーザ認証機能（国民向け）（パターン2 OSS利用）
ブロック実現例 （#コンテナバックエンド）
ブロック実現例 説明
[1]
[2]
[3]
[4]
利用者認証_ユーザ認証機能（国民向け）（パターン3 ソーシャルログイン機能利用）
ブロック実現例 （#サーバレスバックエンド）
ブロック実現例 説明
[1]
[2]
[3]
[4]
[5]
[注]
利用者認証_ユーザ認証機能（国民向け）（パターン4 小規模システム向け）
ブロック実現例 （#サーバレスバックエンド）
ブロック実現例 説明
[1]
[2]
[3]
[4]
[注]
利用者認証_ユーザ認証機能（国民向け）（パターン5 AWSリソースへの直接アクセス）
ブロック実現例
ブロック実現例 説明
[1]
[2]
[3]
[注]
5-2-1-2. 利用者認証_ユーザ認証機能（企業ユーザ向け）
概要：
達成できる業務：
インタフェース例：
| インプット | 処理内容 | アウトプット |
|---|---|---|
| ・外部のIDプロバイダが発行した認証結果 | ・認証結果が正当なものであることを検証する。（認証結果として、OpenID Connectにおける認可コードや、SAML2.0におけるアサーションを想定） | ・認証済みであることを示すトークンを返却 |
| ・利用者が設定したIDとパスワード | ・登録済みのIDとパスワードと一致するかを確認する | ・認証済みであることを示すトークンを返却 |
| ・ユーザ情報の参照リクエエスト | ・登録済みのユーザ情報を取得する | ・ユーザ情報を返却 |
| ・ユーザ情報の更新データ | ・更新データを受信し、登録済みのユーザ情報を更新する | ・なし |
| ・ユーザ情報の削除リクエスト | ・削除リクエストを受信し、登録済みのユーザ情報を削除する | ・なし |
| ・ユーザ認証機能（企業ユーザ向け）が発行したトークン | ・トークンが正当なものであることを検証する | ・なし |
連携機能ブロック：
利用者認証_ユーザ認証機能（企業ユーザ向け）（パターン1 gBizID連携）
ブロック実現例 （#サーバレスバックエンド）
ブロック実現例 説明
[1]
[2]
[3]
[4]
[5]
[注]
利用者認証_ユーザ認証機能（企業ユーザ向け）（パターン2 小規模システム向け）
ブロック実現例 （#サーバレスバックエンド）
ブロック実現例 説明
[1]
[2]
[3]
[4]
[注]
5-2-1-3. 利用者認証_ユーザ認証機能（職員向け）
概要：
達成できる業務：
インタフェース例：
| インプット | 処理内容 | アウトプット |
|---|---|---|
| ・外部のIDプロバイダが発行した認証結果 | ・認証結果が正当なものであることを検証する。（認証結果として、OpenID Connectにおける認可コードや、SAML2.0におけるアサーションを想定） | ・認証済みであることを示すトークンを返却 |
| ・利用者が設定したIDとパスワード | ・登録済みのIDとパスワードと一致するかを確認する | ・認証済みであることを示すトークンを返却 |
| ・ユーザ情報の参照リクエエスト | ・登録済みのユーザ情報を取得する | ・ユーザ情報を返却 |
| ・ユーザ情報の更新データ | ・更新データを受信し、登録済みのユーザ情報を更新する | ・なし |
| ・ユーザ情報の削除リクエスト | ・削除リクエストを受信し、登録済みのユーザ情報を削除する | ・なし |
| ・ユーザ認証機能（職員向け）が発行したトークン | ・トークンが正当なものであることを検証する | ・なし |
連携機能ブロック：
利用者認証_ユーザ認証機能（職員向け）（パターン1 外部IDプロバイダ連携）
ブロック実現例 （#サーバレスバックエンド）
ブロック実現例 説明
[1]
[2]
[3]
[4]
[5]
[注]
利用者認証_ユーザ認証機能（職員向け）（パターン2 小規模システム向け）
ブロック実現例 （#サーバレスバックエンド）
ブロック実現例 説明
[1]
[2]
[3]
[4]
[注]
利用者認証_ユーザ認証機能（職員向け）（パターン3 Active Directoryと連携）
ブロック実現例 （#サーバレスバックエンド）
ブロック実現例 説明
[1]
[2]
[3]
[4]
[5]
[注]
5-2-8. 外部連携
- 外部システムへ当該行政システム利用の一次権限の付与を行う。
- 機能を呼び出すシステムが正当であることの確認を行う業務
- システムの認証を要する機能
- 申請・届出_申請・届出機能 など
- WebAPIの呼び出し元の認証にはAmazon Cognitoを使用する。
- Amazon CognitoはID管理サービスであり、WebAPIの呼び出し元の管理およびトークン発行等の処理をフルマネージドで実現可能である。
- 外部システムは、OAuth2.0のClient Credentials Grantのフローに従ってWeb APIを呼び出す。
- Amazon Cognitoからトークンを取得し、取得したトークンを用いてWebAPIを呼び出す。
- WebAPIはAPI Gatewayにより構築される。
- API GatewayはAmazon CognitoをWebAPIの呼び出し可否の判断に使用するオーソライザーとして連携が可能である。
- Amazon Cognitoをオーソライザーとして設定することで、トークンの有効性確認の処理をAPI Gatewayに任せることができる。
- WAF(※)によりインターネット経由で行われる様々な攻撃からAPIを保護する。
※WAFのルールグループについては非機能ブロック「セキュリティ_通信を介した攻撃への保護」を参照すること。 - トークンの有効性が確認できた場合は、他の機能ブロックが提供するWebAPIへのアクセスを許可する。
- Amazon Cognitoでは、リクエストレートクォータとして、単位時間あたりのAPI呼び出しに上限が設定されている。リクエストレートクォータを上回る負荷が想定される場合には、Amazon Cognitoではなく、Amazon ECSを利用してコンテナ上で認証認可サーバを独自に構築する方法や、認証認可サーバの機能を提供する外部サービスの利用などの代替案を検討する必要がある
- WebAPIの呼び出し元の認証にはAWS IAMを使用する。
- AWS IAMが提供する一般的なAWSリソースへのアクセス管理と同様に、WebAPIの呼び出し権限を管理する。
- 外部システムは、WebAPIを呼び出す権限を含むIAM Roleを使用する。
- IAM Roleを用いて取得した一時認証情報を使用してWebAPIを呼び出す。
- IAM Roleを使用することで、永続的なアクセスキーを発行することなく、WebAPIへのアクセスが可能となる。
- 外部システムが別のAWSアカウントに存在する場合には、セキュリティに関する追加の設定を考慮することが推奨である。具体的には、外部システムが利用するIAM Roleにおいて、IAM Roleの信頼ポリシーにて、外部システムのAWSアカウントのアカウントIDをPrincipalに指定することに加え、sts
として外部システムごとに一意な値をConditionに指定することで、意図しないアクセス元がIAM Roleを利用するリスクへ対策する。 - WebAPIはAPI Gatewayにより構築される。
- API GatewayはWebAPIの呼び出し可否の判断にIAM認証を設定する。
- IAM認証を設定することで、WebAPIの呼び出し可否の処理をAPI Gatewayに任せることができる。
- WAF(※)によりインターネット経由で行われる様々な攻撃からAPIを保護する。
※WAFのルールグループについては非機能ブロック「セキュリティ_通信を介した攻撃への保護」を参照すること。 - 一時認証情報の有効性が確認できた場合は、他の機能ブロックが提供するWebAPIへのアクセスを許可する。
- AWSリソースのアクセス元の認証にはAWS IAMを使用する。
- AWS IAMによって、AWSリソースへのアクセス権限を管理する。
- 外部システムは、アクセス先となるAWSリソースを呼び出す権限を含むIAM Roleを使用する。
- IAM Roleを用いて取得した一時認証情報を使用してアクセス先のAWSリソースへアクセスする。
- IAM Roleを使用することで、永続的なアクセスキーを発行することなく、AWSリソースへのアクセスが可能となる。
- また、外部システムが別のAWSアカウントに存在する場合には、セキュリティに関する追加の設定を考慮することが推奨である。具体的には、外部システムが利用するIAM Roleにおいて、IAM Roleの信頼ポリシーにて、外部システムのAWSアカウントのアカウントIDをPrincipalに指定することに加え、sts
として外部システムごとに一意な値をConditionに指定することで、意図しないアクセス元がIAM Roleを利用するリスクへ対策する。 - IAM Roleを用いて取得した一時認証情報を使用して、非同期連携またはファイル連携のためのAWSリソースへアクセスする。
- 非同期連携では、Amazon SQS（メッセージキュー）、Amazon SNS（Pub/Subモデルのメッセージ配信。複数の配信先へのメッセージ送信）、Amazon EventBridge（リクエストの内容に応じた配信先のルーティング）が送信先の例として挙げられる。
- また、ファイル連携ではオブジェクトストレージであるAmazon S3が例として挙げられる。
- なお、Amazon EventBridgeでは、Amazon EventBridge PipesによるAWSサービス間の連携も提供されている。Amazon EventBridge Pipesでは、イベントソースとターゲットの連携を自前の実装無しで実件可能であり、イベントのフィルタリングや変換も提供している。
5-2-8-1. 外部連携_システム間認証機能
概要：
達成できる業務：
インタフェース例：
| インプット | 処理内容 | アウトプット |
|---|---|---|
| ・システムに発行したIDとパスワード | ・登録済みのIDとパスワードと一致するかを確認する | ・認証済みであることを示すトークンを返却 |
| ・一時認証情報の発行リクエスト | ・事前設定した権限情報（IAM Role）にしたがって一時認証情報を発行する | ・一時認証情報を返却 |
| ・外部連携_システム間認証機能が発行したトークンまたは一時認証情報 | ・トークンまたは一時認証情報が正当なものであることを検証する | ・なし |
連携機能ブロック：
外部連携_システム間認証機能（パターン1 WebAPI呼び出しによる認証①）
ブロック実現例 （#サーバレスイベント処理）
ブロック実現例 説明
[1]
[2]
[3]
[4]
[注]
外部連携_システム間認証機能（パターン2 WebAPI呼び出しによる認証②）
ブロック実現例 （#サーバレスイベント処理）
ブロック実現例 説明
[1]
[2]
[3]
[4]
外部連携_システム間認証機能（パターン3 非同期連携、ファイル連携）
ブロック実現例
ブロック実現例 説明
[1]
[2]
[3]
5-2-11. セキュリティ
- 発見的統制に抵触する操作、設定、脆弱性の有無を検知し、ダッシュボードへの表示と通知を行う。
- セキュリティ管理および検知などの業務
- 管理対象セキュリティデータの収集
- 各機能（業務アプリケーション）
- Amazon InspectorにてAWS Lambdaの関数ソースコードおよびAmazon ECRで保管するコンテナイメージに対する脆弱性のスキャンを行う。
- VPC Flow logやDNSクエリログ、AWS操作ログ（CloudTrail）、Aurora不正操作をGuradDutyにて情報収集し、異常検知を行う。
- Amazon Macieにて、S3の情報から機械学習により機密情報の検査を行う。
- AWS Config Rulesにて、AWS リソースの設定内容を評価を行う。
- IAM Access Analyzerにて、AWSリソースのIAMポリシーを検証する。
- AWS Shieldにて、DDoS攻撃に対する保護を行う。
- [1]〜[5]それぞれで検出した脅威の情報をAWS Security Hubにて情報集約を行う。
- 対処が必要なインシデントについては、Amazon EventBridgeに連携する。
- AWS Lambda、Step Functions、Systems Managerを使用して必要な復旧・対処を行う。
- 検出結果を、運用者がAWS Security Hubコンソールにアクセスして確認する。
- [6]の結果を、運用者がAWS Shieldコンソールにアクセスして確認する。
- 必要に応じて、Amazon Detective コンソールにアクセスして視覚化されたデータから分析する。（Amazon Detective有効化が必要）
- 利用システムへのセキュアなアクセス実現する。
- 利用システムへのセキュアなアクセス実現する
- 通信を介した攻撃への保護が必要な機能ブロック
- 各機能（業務アプリケーション）
- Amazon Route 53にて、ドメインを利用した通信を行うための、DNS機能を提供する。
- ドメインの取得・管理を行う。
- AWS Shield Advancedにて、DDoS攻撃保護を行う。(AWS Shield Advancedの月額料金については、Organizations管理アカウントへの請求となり、利用アカウント側には発生しない。)
- 保護対象リソースは、Route53、CloudFront、ELBである。
- AWS WAFにて、通信を介した攻撃保護を行う。各業務機能ブロックで使用しているフロントAWSリソース（ELB、API Gateway、CloudFront）にアタッチすることで機能を有効化する。
- AWSマネージドルールグループの使用が原則であるが、システムの特性上それでは満たされない場合のみMarketplaceで提供されるサードパーティのマネージドルールグループの使用も許容される。ただし、Marketplaceの利用についてはデジタル庁への申請が必要である。詳細については、GCASアカウントを取得の上、GCASガイド（メンバー専用ページ）で公開されているドキュメントを参照すること。
- AWS Network Firewallにて、許可されていない通信をブロックする。
- 必要に応じてIPS機能を有効にする。
- HTTPS通信を必須とする場合は、Amazon CloudFrontで、HTTPをHTTPSにリダイレクトするか、HTTP通信を拒否する。
- セキュリティグループにて、インスタンス向けの許可した通信のみを通過させる。
- 利用システムにおける保管データの暗号化などを実現する。
- 利用システムにおける保管データの暗号化を実現する
- データの暗号化が必要な機能
- 各機能（業務アプリケーション）のデータ保管機能
- ログ管理_ログ管理機能
- バックアップ_バックアップ機能
- データ保護が必要な業務データを分類し、対象データを保管するAWSリソースに対して、AWS KMSで生成したAWSマネージドキーまたは、カスタマーマネージドキーで暗号化を実施する。（キーの管理や制御が必要な場合や、要件等でカスタマーマネージドキーの利用が指定されている場合等を考慮し、 AWSマネージドキーまたは、カスタマーマネージドキーを選択する。）
- データ保護が必要なログデータを分類し、対象データを保管するAWSリソースに対して、AWS KMSで生成したAWSマネージドキーまたは、カスタマーマネージドキーで暗号化を実施する。
- データ保護が必要なバックアップデータを分類し、対象データを保管するAWSリソースに対して、AWS KMSで生成したAWSマネージドキーまたは、カスタマーマネージドキーで暗号化を実施する。
- KMSキーポリシーとIAMアクセス制御を適切に行い、暗号化キーへのアクセス制御を行う。
5-2-11-1. セキュリティ_セキュリティ管理機能
概要：
達成できる業務：
インタフェース例：
| インプット | 処理内容 | アウトプット |
|---|---|---|
| ・連携機能により生成されたセキュリティ管理情報 （AWS Shield以外） | ・SecurityHubにて集約・管理する。 | ・運用者にてSecurityHubコンソールにて検索・分析可能なデータセット |
| ・連携機能により生成されたセキュリティ管理情報（AWS Shield） | ・AWS Shieldにて集約・管理する。 | ・運用者にてAWS Shiledコンソール（AWS Management Console経由）にて検索・分析可能なデータセット |
連携機能ブロック：
セキュリティ_セキュリティ管理機能
ブロック実現例 （#サーバレスイベント処理）
ブロック実現例 説明
[1]
[2]
[3]
[4]
[5]
[6]
[7]
[8]
[9]
[10]
[11]
[12]
5-2-11-2. セキュリティ_通信を介した攻撃への保護
概要：
達成できる業務：
インタフェース例：
| インプット | 処理内容 | アウトプット |
|---|---|---|
| ・各業務アプリケーションを利用するためのリクエスト通信 | ・ドメインでのアクセスを可能にする。 | ・なし |
| ・通信の暗号化を実施する。 ・通信の暗号化を強制する。（HTTP通信をHTTPSにリダイレクトする。） | ・なし | |
| ・Webアクセスの攻撃に対する保護を実施する。 | ・なし | |
| ・許可されていない通信以外を拒否することで不正通信の防御を行う。 | ・なし |
連携機能ブロック：
セキュリティ_通信を介した攻撃への保護
ブロック実現例
ブロック実現例 説明
[1]
[2]
[3]
[4]
[5]
[6]
5-2-11-3. セキュリティ_保管データの暗号化
概要：
達成できる業務：
インタフェース例：
| インプット | 処理内容 | アウトプット |
|---|---|---|
| ・保管データの入力（ストレージへの格納） | ・データの内容を暗号化する | ・暗号化されたデータ |
連携機能ブロック：
セキュリティ_保管データの暗号化
ブロック実現例
ブロック実現例 説明
[1]
[2]
[3]
[4]
※暗号化の強制について、Amazon S3やAmazon CloudWatch Logsについてはデフォルト暗号化が有効で無効化は不可である。
なお、デフォルト暗号化キーからKMSキーに変更すべきかを、要件に合わせて検討する必要がある。
5-2-12. ネットワーク
-
ガバメントクラウド利用者は「GCASガイド(メンバー専用ページ)」からネットワーク接続の関連ドキュメントを確認すること。
5-2-13. 構成管理
- システム内に展開されたインスタンスなどの設定を管理する。
- IaCとしての構成管理およびインスタンスの構成管理業務
- 管理対象構成情報の収集
- 各機能（業務アプリケーション）
- 環境定義はCDKで実装し、環境構築については、CloudFormationで実行する。
- IaCとして作成されたソースコードがシステム構成を表しており、変更時の差分確認も行うことが可能なパラメーターシート（構成管理）相当になる。
- 各アプリケーションが稼働しているAWSサービスの構成情報を取得してストレージに蓄積し、監査時に変更管理に関わる証跡の保存として利用する。
- 本機能ブロックは、環境定義としてのCDKソースコードをGitリポジトリ(AWS CodeCommit)で管理する前提としている。
- CDKソースコードをGitリポジトリで管理することで、システム構成に対して、以下のような差分確認が行えるようになる。
・Gitブランチ間の比較による各環境の環境定義の差分確認
・Gitタグ間の比較による過去の環境定義との差分確認
5-2-13-1. 構成管理_システム構成管理機能
概要：
達成できる業務：
インタフェース例：
| インプット | 処理内容 | アウトプット |
|---|---|---|
| ・IaCとしての構成管理およびインスタンスの構成管理業務 | ・取得した情報をS3に保存する。 | ・なし |
連携機能ブロック：
構成管理_システム構成管理機能
ブロック実現例
ブロック実現例 説明
[1]
[2]
[3]
5-2-14. バックアップ
- システム内のインスタンス・サービスの設定およびデータを管理する。
- システム内のインスタンス・サービスの設定およびデータを管理する機能
- バックアップ対象データの収集
- 各機能（業務アプリケーション）
- AWS Backupのバックアッププランとして、バックアップ取得対象の設定を行う。
- バックアッププランで設定したルールに従って、バックアップが実行される。
- AWS Backupにより、バックアップデータがBackup vaultに保管される。
- 必要に応じて、バックアップデータのクロスリージョンコピーを実施する。
- バックアップ取得タイミングに業務処理との依存関係がある場合（バッチジョブ実行後の断面でバックアップを取りたい等）、Step Functionsを利用することで他の処理と合わせてオーケストレーション制御が可能。
- 業務依存が無い場合は、AWS Backupにてスケジュール起動する。
5-2-14-1. バックアップ_バックアップ機能
概要：
達成できる業務：
インタフェース例：
| インプット | 処理内容 | アウトプット |
|---|---|---|
| ・連携機能により生成された管理対象リソースのバックアップデータ | ・バックアッププランに従ってバックアップデータを保存する | ・リストア可能なバックアップデータセット |
連携機能ブロック：
バックアップ_バックアップ機能
ブロック実現例
ブロック実現例 説明
[1]
[2]
[3]
[4]
[5]
5-2-15. オブザーバビリティ
- 業務アプリケーションやリクエスト応答性などの監視、および異常時のアラート発報を行う。
- 運用者がシステムに問題が発生していることを知るための監視業務。
- 運用者がシステムの稼働状況を確認する業務（ダッシュボードの提供）
- 監視対象データの収集
- 各機能（業務アプリケーション）
- サービス監視や外形監視、セキュリティ監視等の付加機能
- オブザーバビリティ_サービス状態監視機能
- セキュリティ_セキュリティ管理機能
- システムのインスタンス・サービスの出力するログを集約
- ログ管理_ログ管理機能
- 監視対象の業務アプリケーションの稼働状況を示す様々なメトリクス値をCloudWatch Metricsに保存する。
- 監視対象の業務アプリケーションが生成するログをCloudWatch Logsにて集約する。
- 一部のログについてはメトリクスフィルターを利用してCloudWatch Metricsへ送信する。
- 閾値超過時などの異常検出設定に従い、Alarmを発報する。
- AWS Systems Manager（OpsCenter）でインシデント管理できるようにOpsItemsを作成する。
- Alarm発報時は、CloudWatch AlarmとSNSを利用し、メールで運用担当者に通知する。
- Chatbotを利用してSlackなどのチャットアプリケーションで通知する。
- サービス監視機能やセキュリティ_セキュリティ管理機能で検出したAlarmをオブザーバビリティ_システム監視機能で集約して運用担当者に通知する。
- CloudWatch Logsからログ管理_ログ管理機能ブロックに対してログ可視化や分析のためにログ転送を行う。
- CloudWatch Logs、Metrics、Alarmなどを可視化したウィジェットを配置したダッシュボード画面を提供する。
- AWSリリースのメンテナンス情報と障害情報の通知の確認にAWS Healthを使用する。
- 収集したイベント情報をAWS OpsCenterで一覧確認する。
- 利用者目線でのサービス状態（システムの応答時間やレスポンスなど）の監視と通知を行う。
- サービス監視、外形監視（ユーザ目線でのシステム応答テスト）業務
- 監視対象データの収集
- 各機能（業務アプリケーション）
- システム内のインスタンス・サービスの死活監視や性能監視等を行う機能オブザーバビリティ_システム監視機能
- Amazon CloudWatch Syntheticsでサービス監視対象のURL監視（外形監視）を行う。
- Amazon CloudWatch RUMで実際のユーザトラフィック情報を収集し、ユーザ体験やサービスのパフォーマンス把握を監視する。
- 収集したサービス応答時間やエラー発生率等をオブザーバビリティ_システム監視機能のダッシュボード上に表示することで、定量的計測を行う。
- それぞれの計測結果を必要に応じて監視機能ブロックのアラーム機能に連携させる。
- 利用者目線でのサービス状態（システムの応答時間やレスポンスなど）の監視と通知を行う。
- ログやメトリクスを元にKPIをもとめ、ダッシュボード上で可視化をする
- KPIの元となるデータを生成する機能
- (Optional)ログを長期保存する機能
- ログ管理_ログ管理機能
- 本番運用環境上のKPI算出の元となるログはCloudWatch Logsへ出力される。
- 本番運用環境上のKPI算出の元となるメトリクスはCloudWatch Metricsへ出力される。
- CloudWatch LogsのLogs Insights機能により、特定の条件にマッチしたログのカウント数などを算出する。
- (Optional)長期間保管される必要のあるログは、ログ管理機能へサブスクリプションフィルターを利用して連携される。
- 職員は本番監視環境のCloudWatch DashboradへアクセスしKPIを確認する。
- CloudWatch Dashboardで機能が不足する場合はQuickSightなどの活用が推奨される。
- QuickSightの構成例については、「データ管理_分析用ダッシュボード機能」を参照。
5-2-15-1. オブザーバビリティ_システム監視機能
概要：
達成できる業務：
インタフェース例：
| インプット | 処理内容 | アウトプット |
|---|---|---|
| ・連携機能により生成された監視対象となるメトリクス | ・取得した情報を監視し、通知が必要な異常判定を行う。 | ・運用者に問題発生を通知する。 |
| ・連携機能により生成された監視対象となるログ情報 | 同上 | 同上 |
| ・AWSリソースのメンテナンス情報と障害情報 | 同上 | 同上 |
| ・連携機能により生成された監視対象となるアプリケーショントレース情報 | ・なし | ・運用者が閲覧可能なコンソール出力データセット |
連携機能ブロック：
オブザーバビリティ_システム監視機能
ブロック実現例
ブロック実現例 説明
[1]
[2]
[3]
[4]
[5]
[6]
[7]
[8]
[9]
[10]
[11]
5-2-15-2. オブザーバビリティ_サービス状態監視機能
概要：
達成できる業務：
インタフェース例：
| インプット | 処理内容 | アウトプット |
|---|---|---|
| ・連携機能に対して外形監視を行い測定したデータ | ・取得した情報を監視し、通知が必要な異常判定を行う | ・オブザーバビリティ_システム監視機能にアラート連携する |
| ・連携機能に対するクライアント側パフォーマンス情報を測定したデータ | ・取得した情報を監視し、通知が必要な異常判定を行う。 | ・オブザーバビリティ_システム監視機能にアラート連携する |
連携機能ブロック：
オブザーバビリティ_サービス状態監視機能
ブロック実現例
ブロック実現例 説明
[1]
[2]
[3]
5-2-15-3. オブザーバビリティ_KPI可視化機能
概要：
達成できる業務：
インタフェース例：
| インプット | 処理内容 | アウトプット |
|---|---|---|
| ・ログ ・メトリクス | ・ログからメトリクスの生成 | ・メトリクスが可視化されたダッシュボード |
連携機能ブロック：
オブザーバビリティ_KPI可視化機能
ブロック実現例
ブロック実現例 説明
[1]
[2]
[3]
[4]
[5]
[補足]
5-2-16. ログ管理
- システム内のインスタンス、アプリケーションなどが出力するログを集約・管理する。
- システム内のインスタンス・サービスの出力するログを集約・管理する業務。
- 管理対象ログデータの収集
- 各機能（業務アプリケーション）
- システム内のインスタンス・サービスの死活監視や性能監視等を行う機能
- オブザーバビリティ_システム監視機能
- ELBやAmazon CloudFrontのアクセスログを、直接S3に出力させる。
- アプリケーションログ（コンテナ（FireLensログドライバーをサイドカー配置）を必要に応じてCloudWatch Logsや、 Kinesis Data Firehose、S3に出力させる。
- Amazon Aurora、VPC Flow Logs、AWS Lambda、S3の各ログをCloudWatch Logsに出力させる。
- アプリケーションログ（コンテナ（awslogsログドライバー）やLambda）をCloudWatch Logsに出力させる。
- AWS操作ログを取得するCloudTrailのログをCloudWatch Logsに転送する。
- CloudWatch Logsのサブスクリプションフィルタを用いてKinesis Data Firehoseにログをストリーミングする。
- Kinesis Data Firehoseでストリーミングのリアルタイム処理を行う。CloudWatch LogsからストリーミングされたログをS3へ保存する。
- 保管したログはCloudWatch Logsで確認する。
- S3に直接保管したログはAthenaで検索し確認する。
- また、CloudWatch Logs Insightsを使用して、CloudWatch Logsのログを検索し確認する。
- ELBやAmazon CloudFrontのアクセスログを、直接S3に出力させる。
- アプリケーションログ（コンテナ（FireLensログドライバーをサイドカー配置）を必要に応じてCloudWatch Logsや、 Kinesis Data Firehose、S3に出力させる。
- Amazon Aurora、VPC Flow Logs、AWS Lambda、S3の各ログをCloudWatch Logsに出力させる。
- アプリケーションログ（コンテナ（awslogsログドライバー）やLambda）をCloudWatch Logsに出力させる。
- AWS操作ログを取得するCloudTrailのログをCloudWatch Logsに転送する。
- CloudWatch Logsのサブスクリプションフィルタを用いてKinesis Data Firehoseにログをストリーミングする。
- Kinesis Data Firehoseでストリーミングのリアルタイム処理を行う。CloudWatch LogsからストリーミングされたログをS3へ保存する。
- 保管したログはCloudWatch Logs Insightsを使用して、CloudWatch Logsのログを検索し、確認する。
- オプションでQuickSightやOpenSearchを用いて、可視化し、分析することも可能。
5-2-16-1. ログ管理_ログ管理機能
概要：
達成できる業務：
インタフェース例：
| インプット | 処理内容 | アウトプット |
|---|---|---|
| ・連携機能により生成された集約・管理対象のログ | ・直接S3に保管する | ・Cloudwatch LogsやAthenaでログの確認可能なデータセット・ オプションとして、QuickSightやOpenSearch Serviceで分析・可視化可能なデータセット・ オプションとして、QuickSightやOpenSearch Serviceで分析されたログデータのダッシボード表示（ログの検索等） |
| ・連携機能により生成された集約・管理対象のログ | ・ログデータの抽出・変換を行い、S3に保管する | 同上 |
連携機能ブロック：
ログ管理_ログ管理機能 （パターン1 ログ保管のみ）
ブロック実現例 （#ストリーム処理）
ブロック実現例 説明
[1]
[2]
[3]
[4]
[5]
[6]
[7]
[8]
ログ管理_ログ管理機能 （パターン2 ログ保管後、可視化/分析実施）
ブロック実現例 （#ストリーム処理）
ブロック実現例 説明
[1]
[2]
[3]
[4]
[5]
[6]
[7]
[8]
[8]
5-2-17. CI/CD
- 職員が利用システム上のインフラストラクチャー、アプリケーションの更新のためのコード管理、ビルド、テスト、デプロイ機能を一元的に提供する。
- CI/CD利用するための機能
- システムの認証を要する機能
- 各機能（業務アプリケーション）
- AWS CodeCommitでソースコードの管理を行う。
- AWS CodeBuildでソースコードをビルドテストを実施し、ビルドされたイメージをECRに登録する。
- AWS CodeDeployでアプリケーションを検証環境でテスト済みのコンテナイメージが登録されたECRから本番環境にB/Gデプロイする。
- AWS CodePopelineを用いることで、ソースコードの変更をトリガに一連の流れを自動的に実行するパイプラインを構築する。
- 本番環境のリリースについては、安全のため手動承認フェーズを設ける。
- 開発環境のECRは本番環境・検証環境とば別に用意し、手動イメージ操作を許容する（開発環境の自由度を高め開発効率化を図る目的）が、本番環境・検証環境では許可しない方針とする。
- AWS CodeCommitにコードを登録する。
- AWS CodeBuildでソースコードをビルドテストを実施する。
- ソースリポジトリ（①のCodeCommit）にパイプラインを更新したコードをプッシュするとパイプラインが更新される。
- パイプラインの構築から、インフラ定義まで一連の作業をすべでCDKで実施可能な反面、複雑なパイプラインの構築は不可となる。
- AWS CDKで開発環境および検証環境のデプロイを実施する。
- 検証環境のテストで問題がなければ本番環境のデプロイを実施する。
- CDKはCloudFormationテンプレートを生成し、CloudFormationはリソースの状態をテンプレート通りに変更するため、テンプレート定義が正しいかのテストを行う必要がある。
- デプロイしたリソースについてパラメータ検証だけでなく、動作検証での確認を行う。
5-2-17-1. CI/CD_CI/CDパイプライン機能
概要：
達成できる業務：
インタフェース例：
| インプット | 処理内容 | アウトプット |
|---|---|---|
| ・開発者が作成したソースコード及びテストコード | ・成果物をビルドする。 ・複数の成果物の依存関係を解決する。 ・コンテナイメージを作成する。 ・成果物の単体テストを実行する。 ・成果物の結合テストを実行する ・テスト結果を出力する。 | ・成果物を開発環境に反映する。 ・成果物を検証環境に反映する。 ・成果物を本番環境に反映する |
| ・開発者が承認者に対して実行した承認依頼 | ・本番環境のリリース前の手動承認フェーズを行う | ・成果物を開発環境に反映する。 ・成果物を検証環境に反映する。 ・成果物を本番環境に反映する |
連携機能ブロック：
CI/CD_CI/CDパイプライン機能（パターン1 コンテナアプリケーション）
ブロック実現例
ブロック実現例 説明
[1]
[2]
[3]
[4]
[5]
CI/CD_CI/CDパイプライン機能（パターン2 インフラリソース）
ブロック実現例
ブロック実現例 説明
[1]
[2]
[3]
[4]
本リファレンスアーキテクチャでは、CDKソースコードをGitリポジトリ(AWS CodeCommit)で管理する前提である。
Gitリポジトリでのブランチの更新をトリガーにしてCDKソースコードに対する検証や、各環境へのデプロイを自動化する。また、CDKソースコードのデプロイでは、3つの環境を利用してCDKソースコードの動作確認を行う前提である。
本番環境を変更する際には、開発環境及び検証環境にて必要な変更を含んだCDKソースコードをデプロイし、動作確認を行う。本番環境にデプロイするCDKソースコードを、他の環境で事前に動作確認することで、本番環境の変更を安全に行えるようになる。なお、 CDKをデプロイするためのパイプライン自体を対象とする場合の、AWS CDKではCDK Pipelinesという自己更新機能をもったパイプラインのコンストラクトライブラリモジュールが公開されており、こちらの利用も可能である。
CDK Pipelineneについて： https://aws.amazon.com/jp/blogs/news/multi-branch-pipeline-management-and-infrastructure-deployment-using-aws-cdk-pipelines/Opens in new tab
5-2-18. データ共有
- 複数自治体の情報をDBに保管する際に、自治体ごとに分離せずに統合し、互いに活用するためのデータ格納を実現する。
- 組織横断でのデータ活用する目的で、組織毎に蓄積されるデータセットを複数組織へ共有する業務
- データ利活用について企画・立案する目的で、共有されたデータカタログを検索し、必要となるデータセットを検索する業務
- 分析対象データの収集・保管
- データ管理_データ連携機能
- データ管理_データ収集機能
- データ管理_大量データ取り込み機能
- 共有されたデータセットを利用する機能
- データ管理_統計処理機能
- 利用者の認証
- 利用者認証_ユーザ認証機能（職員向け）
- 本機能ではシステム毎に連携機能により蓄積されたデータを対象とする。
- システム毎に連携機能により蓄積されたデータをGlueジョブによりLake Formation内のS3へETL処理を実施し、共有可能なデータへ変換する。
- CrawlerによりLake Formation内のS3に保管されたデータのメタデータをGlue Data Catalogへ登録する。
- Lake Formation内のS3に保管されたデータのメタデータをGlue Data Catalogで管理する。
- Glue Data Catalogでは共有するデータ、共有されたデータ、非共有データの全てを登録・管理する。
- データへのアクセス権限の管理はLake Formationで一元管理する。
- Lake Formation内のS3に保管された共有データのメタデータはResource Access Managerによりアカウント間で共有する。
- 運用者は共有データの共有、共有の承諾、リソースリンクの作成を実施する。
- 業務分析者はマネジメントコンソールよりGlue Data Catalog管理されたメタデータを参照することが可能である。
- 分析者はデータを活用する連携機能によりGlue Data Catalogに登録されたデータを利用することが可能である。
- 本機能ではシステム毎に連携機能により蓄積されたデータを対象とする。
- システム毎に連携機能により蓄積されたデータをGlueジョブによりLake Formation内のS3へETL処理を実施し、共有可能なデータへ変換する。
- CrawlerによりLake Formation内のS3に保管されたデータのメタデータをGlue Data Catalogへ登録する。
- Lake Formation内のS3に保管されたデータのメタデータをGlue Data Catalogで管理する。
- Glue Data Catalogでは共有するデータ、共有されたデータ、非共有データの全てを登録・管理する。
- Lake Formation内のS3に保管された共有データのメタデータはResource Access Managerによりアカウント間で共有する。
- 運用者は共有データの共有、共有の承諾、リソースリンクの作成を実施する。
- 業務分析者はREST APIによりGlue Data Catalog管理されたメタデータを参照する。 API Gateway及びLambdaにより構築される。
- 分析者はデータを活用する連携機能によりGlue Data Catalogに登録されたデータを利用することが可能である。
5-2-18-1. データ共有_複数組織データ分離格納方法
概要：
達成できる業務：
インタフェース例：
| インプット | 処理内容 | アウトプット |
|---|---|---|
| ・組織毎に連携機能により生成された連携対象となるデータセット（単一/複数） | ・単一及び複数のデータセットに対して事前処理及び共有元となるストレージに格納し、共有する | ・組織横断にて共有されたデータセット（単一/複数） |
| ・共有されたデータカタログに対する参照リクエスト（検索条件付き） | ・共有済みのデータカタログを取得 ・検索条件に応じて、データカタログを絞り込み | ・該当するデータカタログ情報を返却 |
連携機能ブロック：
データ共有_複数組織データ分離格納方法 （パターン1 Lake Formation＋マネジメントコンソール利用）
ブロック実現例 （#サーバレスデータ連携）
ブロック実現例 説明
[1]
[2]
[3]
[4]
[5]
[6]
[7]
データ共有_複数組織データ分離格納方法 （パターン2 Lake Formation＋アプリによる実装）
ブロック実現例 （#サーバレスバックエンド #サーバレスフロントエンド #サーバレスデータ連携）
ブロック実現例 説明
[1]
[2]
[3]
[4]
[5]
[6]
[7]
5-2-19. 機械学習・AI機能
- 機械学習・AIサービスを用いた行政業務のシステム化を実現する。
- ユーザーが入力したプロンプトに応じて適切な資料を参照した上で回答を生成
- ユーザーが入力したテキスト文をフォーマットを定義した文書を参照した上でユーザーが指定したフォーマットへ整形
- UIを提供する機能
- コンテンツ管理_Webページ(静的コンテンツ)公開機能
- 認証機能
- 利用者認証_ユーザ認証機能（職員向け）
- 本機能は職員が省庁内文書を参照し実施する必要がある通常業務において、省庁内文書に対応したチャットボットの導入により、業務効率化（例. 文書の要約生成により内容を把握するための時間を短縮、業務に関連する文書抽出により文書を探すための時間を短縮など）を図るための機能である。
- なお、本機能は、他の機能により提供されるフロントエンドアプリからアクセスされることを想定する。
- ユーザーは他の機能ブロックにおいてユーザ認証を行い、認証トークンを取得する。
- 機械学習サービスによる機能はREST APIとして提供される。REST APIはAPI Gateway及びLambdaにより構築される。
- また。WAFはインターネット経由で行われる様々な攻撃からAPIを保護する。
- ユーザーからのリクエストに応じて起動するLambda関数は、Amazon Kendraへ関連資料を検索する。
- 関連資料が見つかった場合、質問文と併せて資料内容をAmazon Bedrockへ送信する。
- 関連資料の検索に使用するAmazon KendraはPDFやWord等の非構造化ドキュメント及びFAQを記述したCSVまたはJSONファイルの構造化ドキュメントの双方をインデックスとして登録することが可能である。
- また、 Amazon KendraをAmazon OpenSearch Serviceへ置き換えることによりベクトル検索等のより高度な関連資料の検索が可能となる。
- Amazon BedrockはAnthropic Claude2等、日本語に対応した自然言語生成モデルをホストし、入力された質問文及び関連文書内容に応じて回答を生成する。
- 本機能は職員が省庁内等のフォーマットが定められている文書作成する際に整形処理の補助として利用し、業務効率化を図るための機能である。
- なお、本機能は、他の機能により提供されるフロントエンドアプリからアクセスされることを想定する。
- ユーザーは他の機能ブロックにおいてユーザ認証を行い、認証トークンを取得する。
- 機械学習サービスによる機能はREST APIとして提供される。REST APIはAPI Gateway及びLambdaにより構築される。
- また。WAFはインターネット経由で行われる様々な攻撃からAPIを保護する。
- ユーザーからのリクエストに応じて起動するLambda関数は、Amazon Kendraへ関連資料を検索する。
- 関連資料が見つかった場合、質問文と併せて資料内容をAmazon Bedrockへ送信する。
- PresignedURL発行関数はS3へデータをアップロードするための時間制限付きPresignedURLを発行し、クライアントへ渡す。
- 職員はPresignedURLでS3へフォーマットを定義した文書をアップロードする。
- Amazon BedrockはAnthropic Claude2等、日本語に対応した自然言語生成モデルをホストし、入力された整形対象のテキスト文及びフォーマット応じて回答を生成する。
5-2-19-1. 機械学習・AI機能_機械学習・AI機能
概要：
達成できる業務：
インタフェース例：
| インプット | 処理内容 | アウトプット |
|---|---|---|
| ・質問文 | ・関連資料を検索する ・関連資料の内容及びプロンプトを元に回答を生成する | ・関連資料の内容に基づいた回答 |
| ・整形対象のテキスト文 ・指定されたフォーマット | ・フォーマットを定義した文書の内容及び入力したテキスト文を元に整形済みのテキスト文を生成する | ・フォーマットを定義した文書に基づいた整形済みのテキスト文 |
連携機能ブロック：
機械学習・AI_機械学習・AI機能 （パターン1 省庁内文書対応チャットボットによる業務効率化）
ブロック実現例 （#サーバレスバックエンド）
ブロック実現例 説明
[1]
[2]
[3]
[4]
[5]
[6]
機械学習・AI_機械学習・AI機能 （パターン2 省庁内文書の作成補助による業務効率化）
ブロック実現例 （#サーバレスバックエンド #ストレージ直接アクセス）
ブロック実現例 説明
[1]
[2]
[3]
[4]
[5]
[6]
[7]
5-2-20. メンテナンス
- プライベートネットワーク内のデータベースに対してインターネット経由で直接操作（定常作業、非定常作業）を行う。
- プライベートネットワーク内データベースに対して実施するメンテナンス業務
- 利用者の認証（定常作業のみ）
- 利用者認証_ユーザ認証機能（職員向け）
- メンテナンス操作対象のデータベース（定常作業、非定常作業）
- 申請・届出_申請・届出機能
- 申請・届出_手数料等電子納付機能
- データ管理_データ収集機能
- コンテンツ管理_Webページ（動的コンテンツ）公開機能
- データ管理_データ連携機能
- 利用者認証_ユーザ認証機能（国民向け）
- 利用者認証_ユーザ認証機能（企業ユーザ向け）
- 利用者認証_ユーザ認証機能（職員向け）
- メンテナンス操作を実行する関数及びサーバーの構築（定常作業のみ）
- CI/CD_CI/CDパイプライン機能
- 構成管理_システム構成管理機能
- メンテナンス操作を実行するサーバーの脆弱性診断及び対処（定常作業のみ）
- セキュリティ_セキュリティ管理機能
- メンテナンス操作の実行ログ及びデータベース監査ログの保管（定常作業、非定常作業）
- ログ管理_ログ管理機能
- 定常作業
- マスターデータ等の業務データに対する更新
- 非定常作業
- オブジェクト定義の更新
- テーブル及び索引の再編成
- ユーザ及びロールの作成/更新
- 実行計画取得等の性能情報取得
- SPA（Single Page Application）における静的ファイル（HTML、JavaScript、CSS）をCloudFront及びS3で配信する。
- ファイルは高耐久なオブジェクトストレージであるS3に保管する。CloudFrontはCDNとしての機能を提供し、大量のリクエストにも低レイテンシーでの応答を実現する。
- WAF(※)によりインターネット経由で行われる様々な攻撃からフロントエンド配信機能を保護する。
※WAFのルールグループについては非機能ブロック「セキュリティ_通信を介した攻撃への保護」を参照すること。 - 運用者は他の機能ブロックにおいてユーザ認証を行い、認証トークンを取得する。
- DBメンテナンス操作はREST APIで送信される。
- REST APIはAPI Gateway及びLambdaにより構築される。
- WAFによりインターネット経由で行われる様々な攻撃からAPIを保護する。
- APIリクエストの認可は認証系の機能ブロックにより発行されるトークンを検証することによって行われる。
- API GatewayはLambda Authorization機能により認証トークン検証関数を起動し、APIリクエストヘッダーに含まれるトークンの有効性を検証する。
- トークンが有効な場合のみ、APIリクエストは受理される。
- 認可された操作は、メンテナンス操作実行関数により実行される。
- メンテナンス操作実行関数内にはデータベースへ接続するためのJDBC等のドライバーを配置し接続する。
- メンテナンス対象のデータベースは他の機能ブロックにより保持される。
- メンテナンス操作実行関数は他の機能ブロックにより構築される。
- メンテナンス操作実行関数の実行ログ及びデータベースの監査ログは他の機能ブロックにより管理される。
- SPA（Single Page Application）における静的ファイル（HTML、JavaScript、CSS）をCloudFront及びS3で配信する。
- ファイルは高耐久なオブジェクトストレージであるS3に保管する。CloudFrontはCDNとしての機能を提供し、大量のリクエストにも低レイテンシーでの応答を実現する。
- WAF(※)によりインターネット経由で行われる様々な攻撃からフロントエンド配信機能を保護する。
※WAFのルールグループについては非機能ブロック「セキュリティ_通信を介した攻撃への保護」を参照すること。 - 運用者は他の機能ブロックにおいてユーザ認証を行い、認証トークンを取得する。
- DBメンテナンス操作はREST APIで送信される。REST APIはAPI Gateway及びECSにより構築される。
- WAFによりインターネット経由で行われる様々な攻撃からAPIを保護する。
- APIリクエストの認可は認証系の機能ブロックにより発行されるトークンを検証することによって行われる。
- API GatewayはLambda Authorization機能により認証トークン検証関数を起動し、APIリクエストヘッダーに含まれるトークンの有効性を検証する。
- トークンが有効な場合のみ、APIリクエストは受理される。
- 認可された操作は、メンテナンス操作実行サーバーにより実行される。
- メンテナンス操作実行サーバー内にはデータベースへ接続するためのJDBC等のドライバーが必要である。
- メンテナンス対象のデータベースは他の機能ブロックにより保持される。
- メンテナンス操作実行サーバーは他の機能ブロックにより構築される。
- メンテナンス操作実行サーバーの実行ログ及びデータベースの監査ログは他の機能ブロックにより管理される。
- 事前に用意したEC2起動テンプレートを用いてメンテナンス操作実行サーバとなるEC2を起動する。
- EC2起動時にユーザデータで定義したコマンドでDB操作に必要なクライアントツールをS3バケットから取得する。
- 運用者は端末からブラウザを開き、マネジメントコンソールにログインする。
- マネジメントコンソールからセッションマネージャーによりEC2へログインする。
- ログインしたEC2からDBクライアントツールによりデータベースへログインし、メンテナンス操作を実施する。
- メンテナンス対象のデータベースは他の機能ブロックにより保持される。
- セッションマネージャー経由でのメンテナンス操作ログ及びデータベースの監査ログは他の機能ブロックにより管理される。
- マネジメントコンソールに対して実施した操作ログは他の機能ブロックにより管理される。
- 本構成ではメンテナンス実行サーバとしてEC2を例に挙げているが、ECSで代替することも可能である。
- 事前に用意したEC2起動テンプレートを用いてメンテナンス操作実行サーバとなるEC2を起動する。
- EC2起動時にユーザデータで定義したコマンドでDB操作に必要なクライアントツールをS3バケットから取得する。
- 運用者は端末からAWS CLIによりIdentity Centerで認証し、一時的な認証情報を受け取る。
- 一時的な認証情報を使用し、AWS CLIによりパラメータストアに保存されたインスタンスID等を取得する。
- 取得したパラメータを入力情報として、AWS CLIを実行しセッションマネージャーを介して、EC2へログインする。
- ログインしたEC2からDBクライアントツールによりデータベースへログインし、メンテナンス操作を実施する。
- メンテナンス対象のデータベースは他の機能ブロックにより保持される。
- セッションマネージャー経由でのメンテナンス操作ログ及びデータベースの監査ログは他の機能ブロックにより管理される。
- AWS CLIにより実施した操作ログは他の機能ブロックにより管理される。
- 本構成ではメンテナンス実行サーバとしてEC2を例に挙げているが、ECSで代替することも可能である。
- 事前に用意したEC2起動テンプレートを用いてメンテナンス操作実行サーバとなるEC2を起動する。
- EC2起動時にユーザデータで定義したコマンドでDB操作に必要なクライアントツールをS3バケットから取得する。
- 運用者は端末からAWS CLIによりIdentity Centerで認証し、一時的な認証情報を受け取る。
- 一時的な認証情報を使用し、AWS CLIによりパラメータストアに保存されたインスタンスID等を取得する。
- 取得したパラメータを入力情報として、AWS CLIを実行しセッションマネージャーを介して、端末からEC2へポートフォワーディングする。
- 端末からDBクライアントツールによりデータベースへログインし、メンテナンス操作を実施する。
- メンテナンス対象のデータベースは他の機能ブロックにより保持される。
- データベースの監査ログは他の機能ブロックにより管理される。
- AWS CLIにより実施した操作ログは他の機能ブロックにより管理される。
- 運用者は端末からブラウザを開き、マネジメントコンソールにログインする。
[2] - マネジメントコンソールから、AWS CloudShellのVPC Environmentを、対象のVPCやサブネット等を指定し作成する。なお、VPC Environmentが作成済みの場合は、作成作業は不要である。
- 作成したVPC Environmentを指定し、AWS CloudShellのターミナルを起動する。
- AWS CloudShellからDBクライアントツールによりデータベースへログインし、メンテナンス操作を実施する。
[3] - メンテナンス対象のデータベースは他の機能ブロックにより保持される。
[4] - データベースの監査ログは他の機能ブロックにより管理される。
- コスト抑制を目的に本番環境以外の環境のリソースをスケジュールに応じて起動・停止する。
- クラウド環境のリソースの起動および停止をスケジュールに従って実施する業務
- 起動および停止の対象となるリソースを有する機能
- 申請・届出_申請・届出機能
- コンテンツ管理_Webページ(動的コンテンツ)公開機能
- 利用者認証_ユーザ認証機能（国民向け）など
- 本機能ブロックは、コストへの影響が大きいリソース(データベースまたはコンピューティング)を自動的に起動または停止することで、コストの最適化を図るものである。
- 起動または停止の対象として、検証環境を主に想定する。検証環境は、エンドユーザが操作する環境では無いため、常時稼働する必要性が低いからである。
- Amazon EventBridge Schedularの機能を使用し、起動停止処理を呼び出す。 Amazon EventBridge Schedularは、cron等のスケジュール形式をサポートするサーバレススケジューラである。
- AWS Lambdaにより、リソースの起動または停止の処理を、対象のリソースの合わせて行う。例えば、Amazon DocumentDBを停止する場合には、クラスターの停止を実行し、Amazon ECS サービスを停止する場合には、ECSサービスにおけるECSタスクの必要数を変更する。
- なお、起動または停止の対象とするAWSサービスについては、起動や停止に関する制限事項(例. Amazon RDSでは、DBインスタンスをの7日間以上の停止ができない)の有無を別途確認することが推奨される。
- オプションとして、AWS Systems ManagerのChange Calendarを組み合わせることが可能である。
- Change Calendarは、カレンダーとして日付と時刻の範囲を設定できるマネージドサービスである。
- Change Calendarと組み合わせることで、Amazon EventBridge Schedularでは設定できないようなスケジュール(祝日の設定や、業務特有のイベントなど)に対応することができる。
5-2-20-1. メンテナンス_DB直接メンテナンス機能
概要：
達成できる業務：
インタフェース例：
本ブロックはデータベース操作方式の例示であり、特定の処理はないため本項記載は割愛する。
連携機能ブロック：
本ブロックが連携する機能ブロックは定常作業、非定常作業で異なる。
本ブロックにおける定常作業と非定常作業について
定常作業と非定常作業をそれぞれ以下を想定し機能ブロックを記載している。
メンテナンス_DB直接メンテナンス機能 （パターン1 定常作業、Lambda経由での操作）
ブロック実現例 （#サーバレスバックエンド #サーバレスフロントエンド）
ブロック実現例 説明
[1]
[2]
[3]
[4]
[5]
[6]
[7]
[8]
メンテナンス_DB直接メンテナンス機能 （パターン2 定常作業、ECS経由での操作）
ブロック実現例 （#サーバレスバックエンド #コンテナバックエンド）
ブロック実現例 説明
[1]
[2]
[3]
[4]
[5]
[6]
[7]
[8]
メンテナンス_DB直接メンテナンス機能 （パターン3 非定常作業、AWSコンソール+SSMを介したEC2経由での操作）
ブロック実現例
ブロック実現例 説明
[1]
[2]
[3]
[4]
[5]
[6]
[7]
メンテナンス_DB直接メンテナンス機能 （パターン4 非定常作業、AWS CLI+SSMを介したEC2経由での操作）
ブロック実現例
ブロック実現例 説明
[注]
[1]
[2]
[3]
[4]
[5]
[6]
[7]
[8]
メンテナンス_DB直接メンテナンス機能 （パターン5 非定常作業、AWS CLI+SSM+ポートフォワーディングを介したEC2経由での操作）
ブロック実現例
ブロック実現例 説明
[注]
[1]
[2]
[3]
[4]
[5]
[6]
[7]
[8]
メンテナンス_DB直接メンテナンス機能 （パターン6 非定常作業、AWSコンソール+CloudShell VPC environment経由での操作）
ブロック実現例
ブロック実現例 説明
[1]
プライベートネットワーク上のデータベースにアクセスする際の注意事項
インターネット経由でプライベートネットワークのデータベースにアクセスする必要がある場合、定常作業では踏み台サーバ相当の仮想マシンの常設を認めていない。
定常作業でアクセスする際はアプリケーションに機能を持たせ、踏み台サーバは構成しない方式を検討いただきたい。非定常作業でのEC2利用における運用について
非定常作業でEC2を介したデータベースアクセスが必要となる場合、下記の運用ルールをもとに各システムで運用手順を準備して意図しないEC2の起動や利用が起こらないよう歯止めいただきたい。
項番 運用ルール 運用手順 1 緊急時・障害時のみEC2を起動して利用すること。 EC2起動テンプレートを使用することで効率性、正確性を向上させるため、項番2以下に従って起動テンプレートを作成し、EC2を起動する。 2 EC2起動時は、常に最新のAMIを使用することで、脆弱性の混入を最小限に抑えること。 EC2起動テンプレートでは最新AMIを指定できないため、起動時にクイックスタートAMIより最新のAMIを指定する。
なお、クイックスタートAMIにクライアントツールは含まれていないため、S3などに資材を事前格納し、EC2起動時のユーザデータを用いたコマンド自動実行で資材取得、インストールする。3 IAMロールの権限は必要最小限とすべきのため、Session Managerで接続するためのIAMロールを作成して、アタッチすること。 要件に合わせてIAMインスタンスプロファイルを作成する。
作成したIAMインスタンスプロファイルをEC2起動テンプレートにて指定する。4 インターネットアクセスできないようにプライベートサブネットに配置すること。 EC2起動テンプレートにてデプロイするプライベートサブネットを指定する。 5 意図しない利用や課金、また、脆弱性への攻撃を防ぐため作業終了後はEC2を必ず終了すること。 EC2終了を行う。 非定常作業でのAWS CloudShell VPC Environment利用における注意点について
非定常作業でAWS CloudShell VPC Environmentを介したデータベースアクセスを実施する場合、下記の注意点を考慮し、メンテナンス作業の実施に支障がないことを事前に確認する必要がある。
項番 項目 内容 1 環境数 IAM プリンシパルごとに作成できるVPC Environmentは2つまで 2 ファイルのダウンロード・アップロード VPC Environmentでは、AWS CloudShellのアクションメニューにあるダウンロードとアップロードは使用不可 3 永続ストレージ VPC Environmentではサポートなし。ターミナル内のデータはセッション終了時に自動削除 4 インターネットアクセス NAT Gatewayへのルートを持つサブネットにVPC Environmentを作成した場合のみインターネットへのアクセスが可能 5 セッション時間 キーボードまたはポインタを20～30分間操作しない場合、セッションは終了。操作している場合でも、 約12時間を上限にセッションは終了。なお、プロセスが実行中であっても、操作しているとは見なされない 6 操作ログ 記録されない 7 コンピューティング性能 1vCPU、2GiBメモリで固定であり、増強は不可 AWS CloudShellのサービスクォータと制限：https://docs.aws.amazon.com/ja_jp/cloudshell/latest/userguide/limits.htmlOpens in new tab
5-2-20-2. メンテナンス_起動停止スケジューリング機能
概要：
達成できる業務：
インタフェース例：
| インプット | 処理内容 | アウトプット |
|---|---|---|
| ・リソースの起動リクエスト | ・クラウド環境のリソースに対して、起動数を増やす処理または起動ステータスへの変更を行う | ・なし |
| ・リソースの停止リクエスト | ・クラウド環境のリソースに対して、起動数を減らす処理または停止ステータスへの変更を行う | ・なし |
| ・リソースの起動および停止スケジュールの登録・修正リクエスト | ・クラウド環境のリソースの起動および停止スケジュールに対して、リクエストの内容を保存する | ・なし |
連携機能ブロック：
メンテナンス_起動停止スケジューリング機能
ブロック実現例 （#サーバレスイベント処理）
ブロック実現例 説明
[1]
[2]
[3]
5-2-21. コスト管理
- システムが利用しているクラウドサービス利用料金が予算超過をしていないかを監視する
- 運用者がシステムが利用しているクラウドサービス利用料金が予算超過をしていないかを監視するコスト管理業務
- クラウド使用料金を参照する分析用のコストダッシュボード確認業務
- あらかじめサービス使用料金を予算額(USD)として設定し、設定した料金に実績が近づいた場合の通知条件を（例 予算の80%超過等）をAWS Budgetsにて設定する。
- サービス使用料が通知条件に達した場合に、Amazon SNSを利用し、メールで運用担当者に通知する。
- AWS Chatbotを利用してSlackなどのチャットアプリケーションで通知する。
- 閾値超過時などの通知を受信した場合、運用者は、AWS Cost Explorerで実際の使用状況を確認する。
- オプションでAWS Cost & Usage ReportとQuickSightを用いて、コスト使用状況の詳細を可視化し、分析することも可能。
- 課金の通知に関しては、必須適用テンプレートにすでに組み込まれているため、利用システム側での追加の実装は不要。
5-2-21-1. コスト管理_課金管理機能
概要：
達成できる業務：
インタフェース例：
| インプット | 処理内容 | アウトプット |
|---|---|---|
| ・各リソース使用状況から使用料金を収集 | ・クラウド利用料を監視し、閾値判定を行う | ・運用者にコスト使用料金の閾値超過を通知 |
連携機能ブロック：
特になし
コスト管理_課金管理機能
ブロック実現例
ブロック実現例 説明
[1]
[2]
[3]
[4]
[5]
[補足]
改訂履歴
| 改訂年月日 | 改訂理由 |
|---|---|
| 2023 年 11 月 2 日 | 新規作成 |
| 2023 年 12 月 22 日 | 業務ブロックおよび非機能ブロックの並び替え、名称変更、拡充 |
| 2024 年 03 月 29 日 | 業務ブロックおよび非機能ブロックの追加、更新 |
| 2024 年 03 月 29 日 | 業務ブロックおよび非機能ブロックへの方式パターンタグを付与 |
| 2024 年 10 月 01 日 | 業務ブロックの更新 |
| 2024 年 11 月 29 日 | 業務ブロックの更新 |
| 2024 年 12 月 26 日 | 業務ブロックの更新 |
| 2025 年 03 月 28 日 | 業務ブロックの更新 |