スライドタイトル／TakaoPGothic

(1)

特権ID不正利用による

マイナンバー情報保護対策

株式会社アシスト

15：15～15:40

(2)

_{マイナンバーとは}

・国民一人ひとりに与えられる12桁の番号

・年金や納税などの情報を一元的に管理する

共通番号制度(マイナンバー制)

納税や年金、医療

などに関する手続き

が簡素化

生活保護の

不正受給防止

生活保護費

不正受給の防止

正確でスムーズな

手続き

(3)

_{マイナンバー導入のデメリット}

・マイナンバーを使って名寄せが出来る

１つの番号で個人にまつわる

あらゆる情報がひもづいてしまう

山田太郎

MS12345

1983/04/01

12-345-678

TARO YAMADA

東京都墨田区○×

ABC

１２３ A

ヤマダタロウ

株式会社▽▲

123456789012

TARO YAMADA

東京都墨田区○×

123456789012

山田太郎

1983/04/01

123456789012

ヤマダタロウ

株式会社▽▲

(4)

漏洩した時のインパクトは計り知れない

だからこそ、漏洩しないように対策が必要

(5)

_{安全管理措置として提示された6項目}

基本方針の策定

取扱規定書の策定

技術的安全措置

物理的安全措置

組織的安全措置

・アクセス制御

・アクセス者の識別と認証

・外部からの不正アクセス等の防止

・情報漏洩等の防止

＜安全管理措置として提示された6項目＞

具体的な手段は各社の判断に委ねられる

(6)

イチから始めるのではなく、見直しを。

今まで実施してきた情報漏洩対策を見直して、

弱いところや

抜けていたところへの対策を

。

顧客情報

製品情報

社員情報

マイ

ナンバー

標的型攻撃

人的ミス

内部犯行

企業の資産（＝データ)

標的型攻撃対策もマイナンバーの技術的措置も

企業が守るべきものは同じ、『データ』です。

(7)

_{データを護る対策ポイント}

特権ID

ログ分析

データ保護

内部不正

関係者

標的型攻撃

マルウェア（攻撃者）

(8)

（前提）

マイナンバー情報の元はサーバにあることが多い

（ポイント）

サーバの利用は申請/承認ベースが原則

ログイン時のワンタイムパスワード/パスワード隠ぺいと

ログイン経路の限定による対策効果は高い

面倒でも厳格な権限分掌はやるべき



ログイン後のアクセス制御とログ取得が最も重要

特権IDの不正利用防止がマイナンバー情報保護対策に有効

(9)

_{申請・承認・パスワード管理}

DB

NW/サーバ/OS

W/F

承認者

申請者A

申請者B

OK

NG

ワンタイムパスワード

パスワード隠ぺい

(10)

_{重要データ(マイナンバー情報）へのアクセス制御}

DB

NW/サーバ/OS

W/F

承認者

申請者A

申請者B

OK

NG

ワンタイムパスワード

パスワード隠ぺい

意図的な悪意には情

報がある場所での

「アクセス制御」

「ログ取得」

が重要

(11)

１、利用は申請/承認ベースが原則

⇒入口対策として対応されているお客様も増えている。

２、ログイン時のワンタイムパスワード/パスワード隠ぺいと

ログイン経路の限定による対策効果は高い

⇒課題１：パスワードを変えたいが、パスワードを変えられ

ないユーザがいる。パスワードが窃取されると

不正ログインを防げない。

３、厳格な権限分掌を行い、ログイン後のアクセス制御と

ログ取得を行うことが最も重要

⇒課題２：権限分掌が進まず、ログインしたあとはなんでも

できてしまう。

課題

(12)

・課題１：パスワードが変えられないユーザがいる。

パスワード窃取→不正ログインは避けられない。

課題１

パスワードを変更したい（※1）が、サーバ内のどこで

パスワードを参照しているかわからず、変更ができない。

変更した場合の影響度がわからないため、変更する

リスクが高いし、影響度を確認しようとすると時間や

コストがかかってしまう。

起動中のプログラムやサービス

システム停止により、

業務に多大な影響を

与えてしまう。

システム管理者

パスワード変更

パスワードが

違うため起動しない

※1：パスワードの定期変更が行われない場合、部署異動したユーザが不要なアクセスができたり、

不正プログラムの攻撃を受け続けてしまいます。

(13)

_課題２

権限分掌の設定をするのが大変で、実施できていない。

管理者権限でログインしているため、ログイン後は作業を

実施したついでになんでもでき、個人情報を含んだファイ

ル等にも自由にアクセスできてしまう。

・課題２：特権IDでログインしたあとはなんでも

できてしまう。

重要なデータを

もったサーバ

悪意をもったユーザ

重要なデータをもった

データベース

重要なデータをもった

ファイル

データベースへ

アクセス

ファイルへ

アクセス

重要なデータに簡単に

(14)

_{特権ID管理～全体像}

マイナンバー情報

自動ログイン

各業務サーバのOSアカウントに対し、特権IDパスワード貸し出しに加え、重要情報に対して

きめ細かい

アクセス制御、操作ログ

の取得を実現します。

申請・承認

パスワード貸出

特権ID管理ソリューションの全体像

【申請者】

【承認者】

パスワード貸出

システム

アクセス制御

システム

パスワード隠蔽

(15)

_{特権ID管理～IDの貸出管理}

ポイント１：パスワード貸出システム(SAM)による共有アカウント管理

パスワード変更（貸出用）

パスワード変更（利用後）

パスワード貸出

特権ID利用申請

特権ID承認

SAM（※1）で、

「特権ID（Administrator等）を共有したまま管理する運用」

の問題を

改善します。本製品を導入することにより、

「パスワード貸出」

を簡易に実施します。

パスワード貸出履歴

【業務サーバ】

【申請者】

【承認者】

エージェントレス

SAM

【パスワード貸出業務の流れ】

(16)

_{特権ID管理～アクセス制御（全体像）}

TCP受信

_ログイン

su

_{ファイルアクセス}

_TCP送信

すべてPIMで制御可能！！

PIM（※1）は、各サーバの

「リモートアクセス制御」「ローカルリソース制御」

を実現します。

TCP受信制御

ログイン制御

su制御

ファイルアクセス制御

TCP送信制御

PIM

ポイント2：アクセス制御システム (PIM)によるサーバ内の操作を制御

【サーバにアクセスする際に発生するイベント】

特権ユーザも全機

能制御可能です！

(17)

ポイント2：アクセス制御システム (PIM)によるサーバ内の操作を制御

特権ID管理～アクセス制御（ログイン）

PIM

許可されている

ホスト、ユーザ

許可されていない

ユーザ

×

許可されていない

ホスト

×

ユーザーの特定、経路を限定することにより、

パスワードを変えられないユーザもセキュアに管理可能！！

Administratorでも

接続できない！

許可された端末からしか

アクセスできない！

重要なデータを

持つサーバ

■ログイン制御■

(18)

ポイント2：アクセス制御システム (PIM)によるサーバ内の操作を制御

特権ID管理～アクセス制御（ファイルアクセス）

ログインした後も、データへのアクセスが制御可能！

悪意をもったユーザ

重要なデータをもった

データベース

重要なデータをもった

ファイル

データベースへ

アクセス

ファイルへ

アクセス

許可されたユーザ

×

データへのアクセス

Administratorでも

接続できない！

■ファイルアクセス制御■

(19)

ポイント2：アクセス制御システム (PIM)によるサーバ内の操作を制御

特権ID管理～アクセス制御（ログ取得）

管理者でもどのような動きをしているのか、一目で確認可能！

（どのOS、バージョンでも同じ形式で確認できます。）

①24 Jan 2012 16:33:30 P HOST ssh 180 3 端末A /usr/sbin/sshd

②24 Jan 2012 16:33:30 P LOGIN user1 59 2 端末A SSH

③24 Jan 2012 16:33:37 P SU user1 Read 59 2 USER.root /bin/su 端末A root

④24 Jan 2012 16:33:47 W FILE user1 Read 202 4 /data/sec1.dat /bin/cat 端末A root

⑤24 Jan 2012 16:33:56 D FILE user1 Read 69 2 /data/sec2.dat /bin/cat 端末A root

⑥24 Jan 2012 16:34:03 P FILE user1 Read 59 2 /data/sec3.dat /bin/cat 端末A root

⑦24 Jan 2012 16:34:26 O LOGOUT user1 49 2 端末A

⑧24 Jan 2012 16:40:53 P HOST ftp 180 3 端末B /usr/sbin/xinetd

⑨24 Jan 2012 16:40:53 P LOGIN user2 59 2 端末B FTP

⑩24 Jan 2012 16:41:00 P FILE user2 Read 59 2 /data/sec3.dat /usr/kerberos/sbin/ftpd 端末B user2

⑪24 Jan 2012 16:41:06 O LOGOUT user2 49 2 端末B

改ざん・削除不可

いつ、どこで、誰が、接続を行ったのか確認可能！

P：許可

D：禁止

W：ワーニングモード

O：ログアウト

■ログの取得■

(20)

・権限分掌をして、

ログインした後の操作も、必要以外の操作を

させないこと

（運用者、開発者、管理者、ログ収集アカウント）

・パスワードが変更できないユーザがいるため、

固定パスワードで

あってもログインの制御

ができること

・各サーバからの

重要データ（顧客情報）の持ち出しが制御

できること

・各サーバで

操作したログが統一された形式で確認

できること

適用例（想定要件）

(21)

_{適用例（構成）}

申請・承認

SAM

自動ログイン

■主な設定内容

・各種業務サーバに対して、PIMを導入。

・承認なしでは業務サーバにアクセスできない。

・顧客情報取得するための専用端末を用意。

・アクセスしたファイルのアクセス履歴を取得。

パスワード払出

_PIM

Windows

（マイナンバー情報）

AIX

（マイナンバー情報）

Windows

顧客情報取得端末

PIM

【申請者】

【承認者】

パスワード隠蔽

(22)

『運用担当者』『開発者』『管理者』『ログ収集アカウント』を用意し、ログイン後にできる

操作を限定

適用例（設定概要①）

OS・DB起動 DBアクセス

ファイル

アクセス

SU

ログ取得

運用担当者

○ ×

△

（一部限定）

×

○ 開発者

×

○ △

（一部限定）

×

○ 管理者

○

○ ログ収集アカ

ウント(※1)

×

△

（一部限定）

○

○ ※1：ログ収集は、ログ収集製品でログを収集するか

お客様自身で設定していただく必要がございます。

(23)

・顧客情報を取得する際は、専用端末を経由しないと持ち出しができない。

適用例（設定概要②）

PIM

持ち出し可能ユーザ

持ち出し不可ユーザ

（参照のみ）

ファイルサーバ

顧客情報取得端末

ファイルサーバ

共有フォルダへコピー

×

・ワークフローは、通常の申請とフローをわけて、最高責任者の承認をえないと

サーバにアクセスできない。

・内部統制を行う部門が監査者となり、申請内容と実際の操作した内容に

問題がないか、SAM・PIMから情報を取得し、確認を行う。

(24)

・パスワードを変更できないユーザがいたが、

パスワード固定の

まま

で、希望するアクセス制御をかけることができた。

・

アクセス制御とログ取得が一緒に管理

できるため、設計や管理を

楽に行うことができた。

・Windows、AIXなど、OSやバージョンが異なる環境があったが、

同じIFで設定ができる

ため、ルール設計だけに専念することが

できた。

・

ワーニングモード（シミュレーションモード）

で動きを確認

できたので、実環境に影響を与えることなくリリースができた。