TORIPIYO DIARY

recent event, IoT, programming, infrastructure topics

GCPの監査ログの概要を理解する

GCPの利用

最近、会社のセキュリティ設定監査のためにGCP環境をよく触っている。GCPはあまり使ってこなかったけど、プロジェクト(AWSで言えばルートアカウントみたいなもの)の切り替えがスムーズだったり、デフォルトでデータが暗号化して保存されるようになっている場合(セキュリティ的に助かる)が多いなど、AWSよりも快適と思うところもある。(IAMのポリシー設定は慣れていないだけなのかもしれないけど、AWSの方が良く感じる)

パブリッククラウドのセキュリティ設定の監査をしていて、外せないのは、監査ログを取得するように設定されているかどうかということ。AWSの場合は、CloudTrailを利用すれば監査ログが取得できるようになる。GCPの場合は、Cloud Audit Logsというサービスを利用して監査ログを取得する。

Cloud Audit Logs と Cloud Logging

Cloud Audit Logsは、Cloud Loggingのログの一種。GCPでは、Cloud Loggingを利用して、GKEで動いているコンテナアプリのログなど色々なログを取得できる。(最初、Cloud LoggingとCloud Audit Logsの関係性がよくわからなくて少し混乱した。AWSのように、監査ログは CloudTrail と完全に独立しているわけではない。)

Cloud Audit Logs の4種類のログ

Cloud Audit Logsは、GCPの監査ログであり、以下の4種類に分類される。

  • Admin Activity audit logs
  • Data Access audit logs
    • リソースの設定やメタデータ参照するAPI呼び出しや、ユーザによって提供されたデータの作成、参照・修正をするAPI呼び出しを記録
  • System Event audit logs
    • Google Cloudによるリソース設定の修正操作を記録、Googleのシステムによって生成される(ユーザによる操作ではない)
  • Policy Denied audit logs

4種類もあるので、これも最初は混乱した。例えば、GCS(Cloud Storage)のオブジェクトへの参照ログを確認するには、どのログを見れば良いのか、わからなかったからだ。(今なら、Data Access audit logsを見れば良いと分かるけど)

これら4種類のログはサービスによっては4種類全て取得されるわけではない。こちらに、各サービスはどのタイプのログを記録できるのかが一覧で掲載されている。

例えば、Cloud Storageでは、Admin Activity audit logs と Data Access audit logs は取得できるが、System Event audit logs と Policy Denied audit logs は取得できない。ほとんどのサービスで、 System Event audit logs と Policy Denied audit logs は取得できないらしい。

また、4種類のログのデフォルトの保管期間は異なる。Admin Activity audit logs と System Event audit logs の保管期間は400日だけど、Data Access audit logs と Policy Denied audit logs の保管期間は30日なので監査上問題の起こりそうな場合はデフォルトの設定から変更する必要がある。

Data Access audit logs の3種類のログ

Data Access audit logsは、さらに3種類のログに分類される。(慣れたら分かるのかもしれないけれど、AWSに比べると本当細かく分類されている。。)

  • ADMIN_READ
  • DATA_READ
    • ユーザによって提供されたデータ参照を記録
  • DATA_WRITE
    • ユーザによって提供されたデータ書き込みを記録

GCS(Cloud Storage)なら、各操作のログは以下のように分類される。

  • Admin Activity audit logs

    • バケットの作成・削除、IAMポリシーの変更、オブジェクトのACL設定の変更 など
  • Data Access Audit logs

    • ADMIN_READ
    • DATA_READ
      • オブジェクトデータの参照、オブジェクトメタデータの参照、オブジェクトの一覧表示、オブジェクトのコピー など
    • DATA_WRITE
      • オブジェクトデータの作成・削除、ACL設定されていないオブジェクトのメタデータの更新、オブジェクトのコピー など

一部の操作(例:オブジェクトのコピー など)では、複数の分類に含まれることもある。例えば、コピー操作であれば、参照と書き込みの両方が実行されるから両方に含まれる。

このように、具体例を見れば確かにその分類に入りそうな操作が記録されてると分かる。ただし、GCPAWSと比べるとログの分類が細かいのでやっぱり慣れは少し必要だと思う。

FP3級を受けてきました

本日、FP3級を受けてきました。公式の解答を用いた自己採点の結果は、合格。

なぜ、FP3級を受けたのかというと、

  • ふるさと納税や米国株の外国税額控除で確定申告するようになってより税金に興味を持つようになった
  • 米国の個別株の頻繁に売買するようになって、投資商品や経済についてもっと詳しくなりたい
  • 引っ越しや不動産投資を考えていて、不動産について知識を身につけたい

といったわけです。

FP3級は、100時間ほど勉強すれば合格できるとあったので、問題集を1冊メルカリで購入して、今年の1月から1日あたり20分ぐらいのペースで勉強を始めました。問題集を解きながら、興味ある内容をインターネットでより深く調べるという感じです。

しかし、4月の中旬ぐらいまで勉強をコツコツとしていて、1日20分だと100日勉強しても33時間(!)の勉強時間なので、受験日までに合格に必要な100時間を確保できない(笑)ことに気づきました。

そこで、4月の下旬から5月の上旬ぐらいまでは1日40分ほど、5月の中旬から受験日前日までは1日2〜3時間、受験日の前日は1日10時間、試験日の当日(笑)は3時間の勉強をして、なんとか100時間ほどの勉強時間を確保して合格できました。

試験日前日の10時間の勉強、実はこれがかなり効いていると思います。FP3級は知っていれば解ける問題が多いのですが、時間が経つと細かい数字を忘れてしまうので、直前に一通りざっと重要な数字は目を通しておくのはとても有効だと感じました。(やっておいて良かった)

FP3級の内容は大きく分けると6分野あって、

と構成されています。金融資産運用以外では知らないことも多く、勉強になりました。特に、不動産、贈与・相続の分野は早めに知っておくことで、騙されたり、余計に税金を払うリスクを減らせるのではないかと思います。

実際、FP3級で出てくる話は最近のニュースでも取り上げられており、背景などの理解が深まります。

次は、財務諸表が読めるように簿記3級を取得したいと思います。

AirTagとレザーキーリングのレビュー

去年の夏、ランニング中に家の鍵を落としました。鍵を紛失したおかげで半日ぐらいの時間を潰して、鍵交換に3~4万円ぐらいかかることとなり精神的なダメージが非常に大きな出来事でした。(結局、親切な人が警察署に届けてくれたので交換はしないで済みました。)

それ以来、発売したら直ぐに購入しようと思っていたのがAirTagです。購入した時には5月の中旬ごろ配送予定となっていましたが、予定が早くなって5月の前半には届きました。鍵につける予定だったので純正のレザーキーリングも購入しています。電池は付属しているので、事前に用意しておかなくても大丈夫です。

AirTag

f:id:ha107chan:20210504161452j:plain
AirTag 4個入りとレザーキーリングのアクセサリ

f:id:ha107chan:20210504161654j:plain
こんな感じで収まっている

AirTagを取り出して、AirTagに挟まっている紙を抜くとiPhoneが直ぐにAirTagを認識してくれるようになります。

f:id:ha107chan:20210504170707p:plain
iPhoneがAirTagを認識

用途に応じてAirTagの名称を選びます。

f:id:ha107chan:20210504170804p:plain
鍵につけるので鍵を選択

これで、iPhoneがAirTagを認識できるようになり、僕のApple IDとこのAirTagが紐づけられました。

"探す"という純正のアプリから、"持ち物を探す"という項目からAirTagの場所を確認できるようになります。実際見てみると、僕の家の場所あたりにAirTagがあると表示されていました。

このアプリを操作して、AirTagから音を鳴らすことも出来ます。音は止める操作をしない限り永遠に鳴り続けるのかなと思ったのですが、数秒で止まるようです。

youtu.be

iPhone12だと、数センチ単位でAirTagの場所を把握できるそうですが、僕はiPhone SEなのでその機能は使えないです。でも、音が鳴れば部屋のどのあたりにありそうかは、なんとなくわかるのでまあ良いかなと思っています。

ちなみに、Apple WatchからAirTagを鳴らせるか試してみましたが、確認した限りでは鳴らすことは出来なさそうでした。

レザーキーリング

レザーキーリングにAirTagはこんな感じで取り付けます。

f:id:ha107chan:20210504163314j:plain
ボタンを外してわっかの間に入れ込む

f:id:ha107chan:20210504163453j:plain
出来上がり

AirTagはわっかにきつく固定されていてボタンもしっかりしているので、普通に使っている限りは落ちることはなさそうです。また、金属の輪もしっかりしているので鍵がキーホルダーから落ちることもなさそうです。


これで、ランニングしていて鍵を落としてもどのあたりに落ちたのかを確認できるようになりそうです。鍵を紛失すると被害は莫大なので、保険の意味でも失くしたらまずいものにAirTagを付けておいてみたらいかがでしょうか。1個だと3800円なのでAppleのアクセサリの中ではそこまで高いものではないと思います。

BigQueryで実行されたSQLを監査ログ(ロギング)から確認する

BigQueryは監査ログを取得できるのか、確認したのでその内容をメモを兼ねて紹介します。

GCPは、AWSのCloudTrailと同じように監査ログを取得できます。ただ、GCPの方がAWSと比べて監査ログの種類が多く、

  • 管理アクティビティ監査ログ
  • データアクセス監査ログ
  • システム イベント監査ログ
  • ポリシー拒否監査ログ

と4つの種類があります。

BigQueryはデフォルトの設定で、”管理アクティビティ監査ログ”, "データアクセス監査ログ", "システム イベント監査ログ" の取得が有効化されています。

実行されたSQLログは、データアクセス監査ログに格納されています。

試しに、以下のSQLを実行してみます。(データは一般公開データセットから適当に取得したデータです。)

select unique_key from `bigquery-public-data.austin_311.311_service_requests`;

f:id:ha107chan:20210419233626p:plain
SQLの実行

このSQLの実行履歴があるかどうか、ログエクスプローラで確認します。

クエリビルダーで、リソースにはBigQueryを選択、ログ名はdata_accessを選択して、クエリを実行のボタンを押します。

そうすると、実行したSQL文をログエクスプローラから確認できます。

f:id:ha107chan:20210419234816p:plain
SQL文をログから確認

データアクセス監査ログは、プライベートな情報が混入可能性があるためなのか、Logging/プライベート ログ閲覧者またはプロジェクト/オーナーという IAM 役割の権限がないとアクセスできないようですので、ログが見えない時は権限不足がないか確認してください。

https://cloud.google.com/logging/docs/audit?hl=ja#data-access

また、データアクセス監査ログの保管期間は30日だそうなので、ある程度前の期間まで監査できるようにしたい場合はGCSやBigQueryに流すようにして、ログが削除される前に退避させるようにしたほうが良さそうです。

https://cloud.google.com/logging/docs/audit?hl=ja#audit_log_retention

SNSとSQSのクロスアカウント設定(KMSで暗号化)

SNSからメッセージをAWSの別アカウントSQSに送ってKMSで暗号化する設定をしたのでやり方を紹介します。

どういうことか分かりやすく図で書くと、以下のようになります。 AWSアカウントA(111111111111)のSNS(simple-sns)から、AWSアカウントB(222222222222)のSQS(simple-sqs)に対してメッセージを送ってKMS(simple-kms)でメッセージを暗号化してSQSで保持するようにします。

f:id:ha107chan:20210409225546p:plain
Account AのSNSからAccount BのSQSにメッセージを送る

手順

アカウントを跨いだクロスアカウントの設定では、権限設定が複雑になり、各リソース(SNS, SQS, KMS)に対してリソースポリシーを設定する必要があります。各リソースに設定するリソースポリシーの説明も手順と合わせて紹介します。

1. SNSトピックを作成 @AWSアカウントA

AWSコンソールからSNSトピックを作成します。

  • 今回は、standardで作成をしました。FIFOでも大丈夫だとは思いますが、検証はしていません。
  • SNS(simple-topic)のリソースポリシーに設定するstatementは以下です。
    • AWSアカウントB(222222222222) から、simple-sns に対する SNS:Subscribe の許可を設定(余談ですが、SNS:Receive は不要かもしれません。コンソールでポリシーを自動作成した時に付与されたのですが、SNSのドキュメントを見ても SNS:Receive の説明はありませんでした。)
{
  "Sid": "__console_sub_0",
  "Effect": "Allow",
  "Principal": {
    "AWS": "arn:aws:iam::222222222222:root"
  },
  "Action": [
    "SNS:Subscribe",
    "SNS:Receive"
  ],
  "Resource": "arn:aws:sns:ap-northeast-1:111111111111:simple-sns"
}

2. KMSを作成 @AWSアカウントB

今度は、AWSアカウントBにログインして、SQSでデータ暗号化の時に利用するKMSを作成します。AWS managed keysでも aws/sqs というエイリアス名でSQSのためのKMSがありますがこれは利用しません。なぜなら、AWS managed keysのリソースポリシーは変更することが出来ないので、SNSがKMSを利用できるように設定できないからです。Customer managed keysを使えば、SNSサービスがSQSのデータを暗号化できるポリシーを設定できます。

  • 適当なエイリアス名でCustomer managed keyを作成して、Key policyには以下のstatementを追加しておきます。
    • このstatementによって、SNSはSQSのデータ暗号化(ViaService)をするときに限ってKMSのGenerateDataKey, Decryptアクションを利用できるようになります。
{
    "Sid": "SnsStatement",
    "Effect": "Allow",
    "Principal": {
        "Service": "sns.amazonaws.com"
    },
    "Action": [
        "kms:GenerateDataKey",
        "kms:Decrypt"
    ],
    "Resource": "*",
    "Condition": {
        "StringEquals": {
            "kms:ViaService": "sqs.ap-northeast-1.amazonaws.com"
        }
    }
}

3. SQSキューを作成 @AWSアカウントB

AWSアカウントAからのメッセージを受け取るSQSを、AWSアカウントBのコンソールから作成します。

  • sqsの名前は、simple-sqsとします。
  • タイプはスタンダードです。
  • この作成時には、Access policyはデフォルトのままにして変更はしません。後で設定します。
  • Encryptionでは、先ほど作成した Customer managed key の エイリアスを指定します。

4. SQS側でSNSをサブスクライブするように設定 @AWSアカウントB

AWSアカウントBのコンソールから、SNSをサブスクライブするようにSQSを設定します。

  1. SQSの設定画面から、"SNS subscriptions" をクリック
  2. "Subscribe to Amazon SNS topic" をクリック
  3. AWSアカウントAのSNSリソース(simple-sns)のARNを入力

    f:id:ha107chan:20210409225947p:plain
    Account A(111111111111)のSNSのARNを設定

  4. "Save" をクリック

    • Subscribed successfully to topic arn:aws:sns:ap-northeast-1:111111111111:simple-sns と緑色の背景で表示されれば成功です。
    • SQSのAccess Policyには以下のStatementが追加されます。
      • SQSのAccess Policyが変更されていることからわかるように、コンソールでの作業ではSQSの操作権限が必要になります。権限エラーになった場合はより強いSQSの捜査権限をもつIAMユーザで作業するか、権限を付与してもらってください。
{
  "Sid": "topic-subscription-arn:aws:sns:ap-northeast-1:111111111111:simple-sns",
  "Effect": "Allow",
  "Principal": {
    "AWS": "*"
  },
  "Action": "SQS:SendMessage",
  "Resource": "arn:aws:sqs:ap-northeast-1:222222222222:simple-sqs",
  "Condition": {
    "ArnLike": {
      "aws:SourceArn": "arn:aws:sns:ap-northeast-1:111111111111:simple-sns"
    }
  }
}

5. SNSからメッセージの送信テスト @AWSアカウントA

  • SNSから適当にテストメッセージを作成して送信します。

f:id:ha107chan:20210409230359p:plain
メッセージの送信

6. SQSからメッセージの受信確認 @AWSアカウントB

  • SQSからPoll for messagesを実行してアカウントAのSNSからメッセージが届いていることを確認します。

f:id:ha107chan:20210409230431p:plain
メッセージの受信


正直、各サービスのリソースポリシーにはどんな権限を付与すれば良いのか混乱すると思います。落ち着いてポリシーをよく見ながら設定してみてください。

参考

地震に備える(地震保険編)

今まであまり地震対策をしていなかったのですが、この前の関東の地震を経験してやっぱりちゃんと対策をとるにこしたことはないと思うようになりました。

Youtubeなどで南海トラフで検索すると以下のように地震動画が出てきます。この動画を見ると、本格的な南海トラフ地震が起きなくても、場合によっては避難所に住まないと行けなくなることがわかります。

www.youtube.com

これから数回に分けて、地震に備えて出来る対策を書いてみようと思います。

地震保険

賃貸用の地震保険には入っていたのですが、内容をよく把握しないで契約をしていたのでこれ機に内容を確認しました。

地震保険は、火災保険に付帯する方式の契約となるので、火災保険とセットでの加入が必要です。地震保険自体の保険料はどこの保険会社でも変わらないようになっているのだそうですが、火災保険の部分で各保険会社の保証内容は異なるので保険の費用も変わってきます。 地震保険の対象は居住用の建物と家財ですが、建物の損傷は基本的に大家負担なので、マンションやアパートを賃貸で借りている場合は家財のみが対象となります。

地震保険は、火災保険と異なって全損しても必ずしも全損した時価額全てが保険金額としておりるわけではありません。例えば、保険金額が1000万円の地震保険を契約していて、2000万円の家が津波で流され全損と認められても、保険金額の100%の1000万円までしか出ません。地震保険に入っている人は、保険金額はいくらに設定されているのかその金額をちゃんと確認するようにしましょう。

地震保険の保険金の支払額は、損害の大きさによって全損・大半損・小半損・一部損に分類されます。分類によって、支払われる保険金額の割合は変わります。

平成29年以降保険始期 基準
全損 地震保険の保険金額の100%
時価額が限度)
大半損 地震保険の保険金額の60%
時価額の60%が限度)
小半損 地震保険の保険金額の30%
時価額の30%が限度)
一部損 地震保険の保険金額の5%
時価額の5%が限度)

全損・大半損・小半損・一部損の分類方法には基準があります。以下は、家財の場合の分類基準です。

平成29年以降保険始期 基準
全損 地震等により損害を受け、損害額が保険の対象である家財全体の時価額の80%以上となった場合
大半損 地震等により損害を受け、損害額が保険の対象である家財全体の時価額の60%以上80%未満となった場合
小半損 地震等により損害を受け、損害額が保険の対象である家財全体の時価額の30%以上60%未満となった場合
一部損 地震等により損害を受け、損害額が保険の対象である家財全体の時価額の10%以上30%未満となった場合

この時価額の被害にあった割合をどうやって計算するのかというと、「食器類」「電気器具類」「家具類」「身のまわり品その他」「寝具・衣類類」の5つに分類して算定する会社が多いそうです。 例えば、地震によってテレビが壊れたとします。この時の家財全体に占める損害の割合は、100万円で購入した高級テレビであっても、1万円で購入した格安テレビであっても一律に同じ割合で計算されます。つまり、テレビが壊れたら2.5%、椅子が壊れたら4%、と品目ごとに割合が決まっていて、その割合の合計で損害の大きさが全損・大半損・小半損・一部損のどれに分類されるのか決まるのだそうです。もし、地震でテレビだけしか壊れなかったら、家財全体の時価額の10%以上とはならないで、地震保険に入っていても保険金は支払われない可能性が高いです。

地震保険の保険金額をどれだけに設定しておけば良いかですが、各保険会社で家族構成や年齢によって家財を再調達する場合にどれぐらいの費用がかかるかの目安を作成しています。これを参考に、どれぐらいの保険金額を設定するか決めることになります。

www.peace-net.jp

地震は発生すると被害は甚大となるため、1回の地震等による保険金の総支払限度額は11.7兆円と決まっているそうです。

www.mof.go.jp

そのため、超巨大地震が発生したら11.7兆円を超えた被害になるので実際に支払われる保険金額はより少なくなるのではという意見もあります。とはいえ、阪神・淡路大震災東日本大震災などの巨大地震が発生した際でもこの金額内でカバーできていたそうで、11.7兆円を超えても何らかの処置を検討してくれるようなので、安心(気休め?)を得るために払うのは悪くないとは思います。自分の場合は安心を得るのにそんな極端に高い額ではないので加入しておこうと思います。

マイナンバーカードの証明書とは

今年は初めてオンラインで確定申告を申請しました(還付申請なら1月1日から申請できます)。カードリーダーにマイナンバーをかざして、確定申告申請のサイトにログインして、オンライン上での記載が終わったら、最後にマイナンバーカードをリーダーにかざして、パスワードを入力してデータを送信することで提出となります。マイナンバーには内部に電子証明書が含まれています。

マイナンバーに含まれる証明書には2種類あります。

これらの証明書は、どちらも地方公共団体情報システム機構(J-LIS)という機関が認証局として発行しているようです。証明書の有効期間はマイナンバーカードが発行されてから5回目の誕生日までとなっています。マイナンバーにはこれら2種類の証明書の公開鍵に対応する、秘密鍵も格納されており、秘密鍵を無理矢理読み取ろうとすると、耐タンパー性により自動的に内容は消去されます。秘密鍵と公開鍵は各地方公共団体で発行されているそうです。

ちなみに、マイナンバーカードの公開鍵を利用してSSHしている強者がいました。

www.osstech.co.jp

利用者証明用電子証明書

利用者証明用電子証明書は、マイナポータルのサイトにログインする際に、カードを所有する利用者本人であることを証明するために利用します。現状だと、ユーザ名とパスワードを入力して本人かどうか判断するサイトが大半ですが、マイナンバーカードを利用した認証方式ではカードを所有していることと、簡単なパスワードの確認で本人かどうかの確認を行っています。

利用者証明用電子証明書に含まれる情報は以下です。氏名・生年月日・性別・住所の情報は含まれません。

  • 発行番号
  • 発行年月日
  • 有効期間
  • 発行者

利用者証明用電子証明書を利用した本人確認の流れは以下の通りです。

  1. マイナポータルなどのサイトで乱数を生成する
  2. 乱数を通信相手のマイナンバーカード所有者に送信する
  3. 乱数を受け取った所有者はマイナンバーカードに格納している秘密鍵でサイトから送られてきた乱数を暗号化する
  4. 乱数本体 + 暗号化された乱数 + 公開鍵情報を含む利用者証明用電子証明書、を所有者からサイトに送信する
  5. サイト側では電子証明書にある公開鍵を利用して暗号化された乱数を復元する
  6. 乱数本体と複合化された乱数を比較して値が一致していることを確認
  7. 認証局地方公共団体情報システム機構(J-LIS))に電子証明書の有効性を照会する
  8. 電子証明書の有効性を確認できたら認証完了

f:id:ha107chan:20210217224336p:plain
利用者証明用電子証明書フロー

本当は、7, 8で認証局には問い合わせないで、認証局によって署名されているかを手元にある認証局の証明書で送られてきたユーザの証明書を検証して終わるのではないかと思うのですが、資料には上記のフローが記載されていました。

なぜ、サイト側で乱数を生成するのかというと、通信相手がマイナンバーカードを所有しているかどうか確認するためです。他人の電子証明書で別人になりすまそうとする人がいても、秘密鍵を利用できるマイナンバーカードが手元にないので、乱数を暗号化することができず、復号化したときに乱数本体の値と一致するような暗号化された乱数を生成できないので乱数の突合でエラーとなります。もし、乱数を生成せずに、純粋にマイナンバーの利用者証明用電子証明書のみで本人確認を行っていたらなりすましは簡単に発生するでしょう。

署名用電子証明書

署名用電子証明書は、文書データが改竄されておらず、マイナンバーの所有者本人によって作成されたことを証明したいときに利用します。例えば、住宅ローン契約の書類を物理的に作成するときは、契約書類には契約者本人の名前を署名すると思います。必要な場合は住所や生年月日も書類に記載します。これと同じことを、署名用電子証明書を使って物理的な紙ではなくて電子データに対して行います。

署名用電子証明書で署名された電子データには、署名者の氏名・生年月日・性別・住所の情報が含まれるようになります。これは、署名者が誰であるか確認できるようにするためです。署名されたデータをむやみにインターネットなどに公開すると個人情報の流出に繋がるので気をつけましょう。

署名用電子証明書には以下のデータが含まれます。

  • 氏名
  • 生年月日
  • 性別
  • 住所
  • 発行番号
  • 発行年月日
  • 有効期間
  • 発行者

名証電子証明書を利用した電子データへの署名の流れは以下の通りです。

  1. マイナンバーカードに格納されている秘密鍵で送信する文書データを暗号化
  2. 文書データ本体と暗号化された文書データ本体と公開鍵のある署名用電子証明書を送信
  3. 送信された公開鍵を利用して暗号化された文書を復号化
  4. 文書データ本体と復号化した文書データを比較して一致することを確認
  5. 送信された電子証明書は有効なものかどうか認証局地方公共団体情報システム機構(J-LIS))に電子証明書の有効性を照会
  6. 有効であれば送信されてきた文書データの有効性の確認完了

f:id:ha107chan:20210217224416p:plain
署名用電子証明書フロー

文書データをマイナンバーカードに格納されている秘密鍵で暗号化することで、送信されてきた文書データがマイナンバーカードを持つ本人によって送信されたものかどうかを確認しています。マイナンバーを持たなければ、秘密鍵を利用できないので証明書の公開鍵によって、復号できるような暗号化された文書データを作成できません。


まとめ

マイナンバーカードには、署名用電子証明書と利用者証明用電子証明書、それら証明書の公開鍵に対応する秘密鍵が格納されています。格納されている秘密鍵を利用しないと、認証や文書データの送信はできないのでマイナンバーカードをしっかりと本人が保管できていれば安全と言えます。しかし逆に言うと、マイナンバーカードと署名用電子証明書・利用者証明用電子証明書の暗証番号が記載された紙を一緒に持ち歩いていて、まとめて盗まれてしまうとシステム上はそのマイナンバーカードを紛失した本人に完全に成り代わって証券口座の開設や不動産取引を行うことが出来るわけです。(不動産取引だと、流石に契約前に実際に会って本人確認をとるのではないかと思いますが。)

もし、マイナンバーカードを登録した暗証番号と一緒に持ち歩いている人がいたら、盗難などされると大変危険なので暗証番号の紙と一緒に持ち歩くことはしないようにしましょう。

参考

マイナンバーと公的個人認証制度の概要について