家studyをつづって

IT技術に関することやセキュリティ、ガイドライン等学んだことをつづっていきます。

SOC(Service Organization Control)について

SOC(Security Operation CenterではなくService Organization Controlのほう)についてまとめてみました。本記事で対象とするSOCとは、監査法人がクラウドベンダーなどにだすお墨付きのようなものです。

SOCはもともと財務諸表監査の延長として取り入れられた制度です。例えば、情報システムの内部統制の監査をする場合に、クラウド等の利用により外部委託のようになっている部分については、自社(監査を受けている企業)ではわからないとなった場合、監査人が都度、ベンダ(上記の場合はクラウドを提供している外部委託先)に、監査をしに行くとなるとベンダ側の負担が大きくなるため、SOCという報告書を作成して監査に対応する目的で作成されました。

SOCにはいくつかの種類があり、公開範囲は利用シーンが異なります。例えばSOC2であればユーザ企業。SOC3は外部に広く公開されます。

f:id:iestudy:20190914224837p:plain

SOCのイメージ

 

SOC報告書別の概要と適用場面 

 

  SOC1 SOC2 SOC3
概要 ユーザと監査人に向けた詳細なレポート ユーザと監査人、特定の関係者(利用予定のユーザ等)に向けた詳細なレポート 一般に公開されるレポート
(SOC2と評価基準は同じだが、広く公開する目的で作成されているため、内容は簡潔なもの)
利用場面 財務報告にかかわる内部統制
財務取引に関するシステムを提供している場合に有用
以下の項目を評価
  • セキュリティ
  • 可用性
  • 機密性
  • 完全性
  • プライバシー
幅広いシステムに適用している


AmazonのSOCレポート
AmazonではSOC3のレポートを公開しています。

aws.amazon.com

 

参考にさせていただいたサイト

https://enterprisezine.jp/article/detail/8923

https://assets.kpmg/content/dam/kpmg/pdf/2016/03/jp-effectively-using-soc-reports.pdf

「SSL/TLS暗号設定ガイドライン」の概要

SSL/TLS 暗号設定ガイドライン

発行機関:情報処理推進機構
発行年月日:2019年5月

https://www.ipa.go.jp/security/ipg/documents/ipa-cryptrec-gl-3001-2.0.pdf

 

概要
このガイドラインは全部で9章で構成されています。

1. はじめに
1.1 本書の内容及び位置付け
1.2 本書が対象とする読者
1.3 ガイドラインの検討体制
2. 本ガイドラインの理解を助ける技術的な基礎知識
2.1 SSL/TLS の概要
2.2 暗号アルゴリズムの安全性
3. 設定基準の概要
3.1 実現すべき設定基準の考え方
3.2 要求設定の概要
3.3 チェックリスト
4. プロトコルバージョンの設定
4.1 プロトコルバージョンについての要求設定
4.2 プロトコルバージョンごとの安全性の違い
5. サーバ証明書の設定
5.1 サーバ証明書についての要求設定
5.2 サーバ証明書に記載されている情報
5.3 サーバ証明書で利用可能な候補となる暗号アルゴリズム
5.4 サーバ証明書で考慮すべきこと
6. 暗号スイートの設定
6.1 暗号スイートについての要求設定
6.2 暗号スイートで利用可能な候補となる暗号アルゴリズム
6.3 鍵交換で考慮すべきこと
6.4 暗号スイートについての実装状況
6.5 暗号スイートについての詳細な要求設定
7. SSL/TLS を安全に使うために考慮すべきこと
7.1 サーバ証明書の作成・管理について注意すべきこと
7.2 さらに安全性を高めるために
8. ブラウザを利用する際に注意すべきポイント
8.1 本ガイドラインが対象とするブラウザ
8.2 設定に関する確認項目
8.3 ブラウザ利用時の注意点
9. その他のトピック
9.1 リモートアクセス VPN over SSL (いわゆる SSL-VPN)

 

2 章ではSSL/TLSや暗号についての基礎知識をまとめています。

f:id:iestudy:20190913234337p:plain

SSL/TLSの概要

3章では、SSL/TLSサーバに要求される設定基準の概要について説明しており、4章から6章では、3章で定めた設定基準に基づき、具体的なSSL/TLSサーバの要求設定について説明しています。

  

SSL/TLS のバージョン概要

バージョン 概要
SSL1.0 リリース前に脆弱性が発見され公開されず
SSL2.0(1994) いくつかの脆弱性が発見されており、なかでも「ダウングレード攻撃(最弱の アルゴリズムを強制的に使わせることができる)」と「バージョンロールバック 攻撃(SSL2.0 を強制的に使わせることができる)」は致命的な脆弱性です。 SSL2.0は利用すべきではなく、2005年頃以降に出荷されているサーバやブラウザではSSL2.0は初期状態で利用不可となっています。
SSL3.0 (RFC6101) (1995)

SSL2.0での脆弱性に対処したバージョンです。2014年10月にPOODLE攻撃が発表されたことにより特定の環境下でのCBC モードの利用は危険であることが認識されています。

POODLE攻撃は、SSL3.0におけるパディングチェックの仕方の脆弱性に起因しているため、この攻撃に対する回避策は現在のところ存在していません。POODLE攻撃の発表を受け、2018年 3月時点での主流の最新版ブラウザでSSL3.0 は初期状態で利用不可となっています。

TLS1.0 (RFC2246) (1999)

2018年3月時点でのSSL Pulseの調査結果によれば、約12万の主要なサイトのうち、TLS1.0が利用できるのは約88%を占めます。ブロック暗号をCBCモードで利用した時の脆弱性を利用した攻撃(BEAST攻撃など)が広く知られていますが、セキュリティパッチも提供されています。

また、SSL3.0で問題となったPOODLE攻撃は、プロトコルの仕様上、TLS1.0 には適用できない暗号スイートとして、より安全なブロック暗号のAES等が利用できるようになりました。

TLS1.1 (RFC4346) (2006)

ブロック暗号をCBCモードで利用した時の脆弱性を利用した攻撃(BEAST攻撃等)への対策を予め仕様に組み入れるなど、TLS1.0より安全性強化を図ってい ます。

規格化された年がTLS1.2とあまり変わらなかったため、TLS1.1とTLS1.2は同時に実装されるケースも多く、2018年3月時点でのSSL Pulseの調査結果によれば約12万の主要なサイトのうち、TLS1.1が利用できるのは約85%にあたります。

TLS1.2 (RFC5246) (2008)

暗号スイートとして、より安全なハッシュ関数SHA-256とSHA-384、CBCモー ドより安全な認証付き秘匿モード(GCM、CCM)が利用できるようになりました。

2018年3月時点でのSSL Pulseの調査結果によれば約12万の主要なサイトのうちTLS1.2が利用できるのは約91%にあたります。

TLS1.3 (draft28)

共通鍵暗号は認証暗号(AEAD: Authenticated Encryption with Associated Data)のみ採用した結果、AES-GCM、AES-CCM、ChaCha20-Poly1305 のみが規定されました。

まだdraftですが、サーバやブラウザで実装が始まっています。

 

f:id:iestudy:20190914000019p:plain

プロトコルバージョンと安全性

 

TLS1.3 の概要
TLS1.3は、TLS1.2策定以降に見つかった新たな脆弱性や攻撃手法への対策を施すと共に、QUIC等のプロトコルに対応するための性能向上を狙いとして、プロトコルと暗号アルゴリズムの抜本的な再設計が行われました。TLS1.2(以前)との差異は以下の通りです。

  • 脆弱なアルゴリズムとして、Triple DES、DSA、RC4、MD5、SHA-1、SHA-224、静的なRSA が削除された。
  • 認証暗号(AEAD)でないAESのCBCモードが削除された。
  • NIST FIPS/SPで規定されていないアルゴリズムとして、共通鍵暗号のChaCha20と署名のEdDSAが追加された。
  • 鍵交換は、DHE、ECDHE、PSKのみが規定され、ECDHEが必須になった。
  • 楕円曲線としてsecp256r1が必須になった。
  • ハッシュ関数はSHA-256が必須になった。
  • 脆弱なハンドシェイク機能として、リネゴシエーション、圧縮、セッション回復が削除された。

f:id:iestudy:20190914000421p:plain

TLS1.2及び1.3の暗号開始個所の比較

 

CRYPTREC暗号リスト
総務省と経済産業省は、暗号技術に関する有識者で構成されるCRYPTREC活動を通して、電子政府で利用される暗号技術の評価を行っており、2013年3月に「電子政府における調達のために参照すべき暗号のリスト(CRYPTREC 暗号リスト)」 を策定しました。

https://www.cryptrec.go.jp/list/cryptrec-ls-0001-2012r4.pdf

 

暗号スイート

暗号スイートは「鍵交換_署名_暗号化_ハッシュ関数」の組によって構成されます。

f:id:iestudy:20190914000731p:plain

暗号スイート例

その他:暗号の歴史

 

区分 概要 代表的な暗号
古代暗号(古典暗号)

現存する最古の暗号は、紀元前3000年頃の石碑に描かれているヒエログリフ(古代エジプトで使われた象形文字)であるとされています。

ヒエログリフは長い間解読不能な暗号とされてきましたが、19世紀にロゼッタ・ストーンの研究が大幅に進み、以降ヒエログラフ解読のきっかけになりました。

シーザー暗号

シーザー暗号は、元の文章のアルファベットをある数だけずらして暗号化するもので、アルファベットを3文字ずらすということをあらかじめ送り手と受け手の間で決めておくものです。

 

スキュタレー暗号
あらかじめある太さの棒を持った暗号文の送り手がその棒に革紐を巻きつ けて棒に沿って文字を書き、その革紐だけを受け手に送るというものです。受け手が同じ太さの棒を持っている場合は、革紐を巻きつけると解読できるという暗号の仕組みになっています。

f:id:iestudy:20190914001012p:plain

スキュタレー
中世暗号(古典)

「シーザー暗号」を始めとする1つのアルファベットを別の文字に置き換えて暗号にする「単一換字式暗号」は数世紀にわたって使用されましたが、次第に解読されていきました。

中世では、古典暗号の解読と新しい暗号の発明によって暗号技術が高度化する一方、外交活動が活発になり秘密情報の増加によって暗号が頻繁に利用される普及期になります。

ヴィジュネル暗号
ヴィジュネル暗号は、ヴィジュネル方陣と呼ばれる表を用いる方式です。
たとえば、GOLDMEDALISTという文章をOLYMPICという鍵で暗号化する場合、原文の文字を表の上端に当てはめ、鍵の文字を表の左端に当てはめて交差するアルファベットが暗号文字ということになります。

f:id:iestudy:20190914001308p:plain

ヴィジュネル方陣
近代暗号 エニグマと呼ばれる機械式の暗号機が登場します。 エニグマの暗号方式は多表式換字式暗号で、「スクランブラー」と呼ばれるアルファベット26文字が刻ま れた数枚の歯車(ローター)と、プラグボードと呼ばれる単文字変換を行う仕組みの組み合わせが「鍵」 になります。まず、スクランブラーをセットした上で、平文をキーボードで打つとスクランブラーを通じて暗 号化された文字がランプボードに表示されます。スクランブラーは1文字打つごとに目盛りひとつ回転するこ とによって、1文字ごとに異なる鍵を使って暗号化することになります。
現代暗号 第二次世界大戦以降暗号の作成と解読は、機械からコンピュータに移っていきました。

DES暗号
DES(Data Encryption Standard)は、1977年に米国商務省標準局(現NIST)によって制定された、 標準のデータ暗号化規格です。
DESでは、64bit単位のデータに対して、ビット位置の変更(転置)やテーブル参照による置き換え(置換)、XOR演算、シフト、繰り返し処理などを組み合わせて、入力されたデータを可能な限り「かき混ぜる」という処理を行います。

 

RSA暗号
ディフィー=へルマンの発明した公開鍵のアイデアを実現する数学的手法は、マサチューセッツ工科大学の 研究者、ロン・リベスト(Ronald L. Rivest)、アディ・シャミア(Adi Shamir)、レオナルド・アドルマン(Leonard M. Adleman)の3人によって発明されました。この公開鍵暗号は開発者3人の頭文字を取って「RSA暗号」と名付けられます。 RSA暗号方式は「素数」による素因数分解を用いる方式です。

https://www.digicert.co.jp/welcome/pdf/wp_encryption_history.pdf

2019年9月のIT・セキュリティトピック

2019年9月に気になったニュースをまとめます。

 

記事の投稿日 概要
2019/08/31 スマホ決済サービスの不正アクセスの被害を補償する保険の取り扱いを三井住友海上火災保険とあいおいニッセイ同和損害保険がそれぞれ始める。
2019/08/31 マネーロンダリング対策における国際協調を推進する政府間機関FATF(金融活動作業部会)は、10月28日から11月15日の3週間に渡り、対日審査することが明らかになった。
2019/08/31

アメリカの400カ所以上の医療機関が一斉にランサムウェア被害に遭う事件が発生した。

2019/08/31 米ツイッター(TWTR.N)のジャック・ドーシー最高経営責任者(CEO)のアカウントが30日午後、何者かにハッキングされ、人種差別的なコメントなどが投稿された。
2019/09/02 Ecサイトの顧客情報を盗まれ身代金を要求される - 日本経営協会
2019/09/02 不正アクセス受けスパムの踏み台に - ロボット開発ベンチャー
2019/09/02 スキャン通信も確認、複数のSSL VPN製品の脆弱性に関する注意喚起 - JPCERT/CC
2019/09/02 IPA、今年上半期の「コンピュータウイルス・不正アクセスの届出事例」を発表
2019/09/02 ADのクラウド展開に役立つサービス:Google、「Managed Service for Microsoft Active Directory」のパブリックβ版を提供開始
2019/09/03 JR西サイトに不正アクセス カード情報盗まれた疑い
2019/09/04 NICTER観測レポート2019上半期公開
2019/09/04 サイバーセキュリティ経営ガイドラインの対応状況を可視化「サイバーセキュリティ評価チェックシート」を無償提供開始
2019/09/05 Facebookの4億人以上のユーザーIDと携帯番号を何者かがアップロード(削除済み)
2019/09/05 ブロックチェーン技術、国際ルール整備へ 金融庁方針
2019/09/05 セガ・インタラクティブ、「maimai動画作成サービス」で不正アクセス 最大3255件のアクセスコードが流出
2019/09/05 みずほ銀行のJコインで不正アクセス
2019/09/05 「FIRST CSIRT Framework Version 2.0」公開(資料自体は2019年7月に公開)
2019/09/06 60万台以上ものGPSトラッカーの情報が「123456」というパスワードでオンライン上に公開されていると ...
2019/09/06 英国のサイバー攻撃最新動向が公開、Office 365が攻撃の標的に
2019/09/06 5億6000万円ものランサムウェア身代金を突っぱねて自力で問題を解決した自治体が現る
2019/09/06 JRグループ会社、個人情報が流出か サイト利用7309人分 /福岡
2019/09/06 金融庁、LINEを仮想通貨交換業者として登録--国内で取引サービス提供へ
2019/09/07 不正アクセスで450人分情報流出 三条・諏訪田製作所 /新潟
2019/09/07 小嶋屋総本店でカード情報流出か 通販サイトに不正アクセス
2019/09/08 悪意あるDDoS攻撃を受け、Wikipediaが欧州の広範囲と中東の一部でダウン
2019/09/09 不正アクセスでクレカ情報流出、不正利用も - 刃物通販サイト
2019/09/09 トヨタ紡織が欧州で最大40億円の詐欺被害、「虚偽の指示で資金流出」
2019/09/10 「キャリア決済」狙うスミッシング - 2段階認証設定でも被害が
2019/09/10 ユーザーのサーバー証明書まで漏洩、守ってくれるはずの専用サービスに障害(Impervaの障害。8月)
2019/09/10 新規登録ドメインの七割が怪しい、作成 32 日未満ドメインはブロック推奨 ~ 1,530 TLD 新規ドメイン調査結果解説(The Register)
2019/09/10 数千のLinuxサーバ、ランサムウェア「Lilu」に感染 - 経路は不明
2019/09/10 法人向けウイルスバスターの脆弱性を突く攻撃発生--パッチ適用を勧告
2019/09/10 パズル通販サイトに不正アクセス - 顧客の問い合わせで判明
2019/09/11 「ビバリーホームページ」へ不正アクセス、フィッシングサイトへ誘導される事象を確認(ビバリー)
2019/09/11 「GEKIROCK CLOTHING」が改ざん被害、カード情報不正取得ページへ誘導(激ロックエンタテインメント)
2019/09/12 グーグルカレンダーに「勝手に予定を追加する」攻撃が急増
2019/09/12 不正アクセス、名前と誕生日は適当(キャリア決済に対するパスワード類推の攻撃)
2019/09/12 「なんとかデータベース」へ不正アクセス、会員情報169,843件が流出の可能性(スープレックス)
2019/09/12 業務用ノートパソコン1台を遺失、遠隔操作でパスワードを複雑化(ゼットン)
2019/09/12 要件定義のノウハウまとめたIPA資料に改訂版 - 成功事例も

「コード決済における不正利用に関する責任分担・補償等についての規定事例集」の概要

コード決済における不正利用に関する責任分担・補償等についての規定事例集(利用者向け利用規約)

発行機関:一般社団法人キャッシュレス推進協議会
発行年月日:2019年8月30日

 

概要
「コード決済における不正利用に関する責任分担・補償等についての規定事例集」は、利用者にキャッシュレス決済を安全に使ってもらうために、利用者に対して情報発信する目的で公開された事例集です。
キャッシュレス決済には、不正利用のリスクがあり、利用者にとっては不安要素の一つになります。
このガイドラインでは、上記の不安を払拭することを目的に、キャッシュレス決済サービスの利用規約の内、不正利用に対しての補償や責任分担等を調査してまとめたものです。

このガイドラインでは、不正利用について以下の2つに分類し、それぞれのケースでの不正利用の保証についてまとめています。

 

  1. 不正利用された本人が利用者アカウントの作成(利用者登録)をした後に、当該利用者アカウントが乗っ取り等により本人以外に利用され、当該利用者アカウント内に本人によってチャージされていた金銭的価値や登録されていたクレジットカード等で決済されてしまう場合
  2. 不正利用された本人は利用者アカウントの作成を行っていないにもかかわらず、第三者により不正に利用者アカウント(不正利用された本人名義とは限らない。)が作成され、当該利用者アカウントにおいて本人のクレジットカードや銀行口座等が登録され、それらを用いて決済されてしまう場合


章構成

はじめに
1.1 補償等に関する規定の重要性
1.2 本事例集の対象
1.3 留意事項
(1) 2 種類の不正利用の存在
(2) 金融機関・他の決済関連事業者等との調整
(3) 関連法令との関係
1.4 用語について
2 本人が利用者登録した場合における不正利用時の責任分担等に関する規定
2.1 総論
2.2 コード決済事業者は責任を負わないとする事例
2.3 コード決済事業者が条件付で責任を負う事例
(1) コード決済事業者に故意重過失があることをコード決済事業者の責任負担の要件とする事例
(2) 利用者が一定の行為を行うことをコード決済事業者の責任負担の要件とする事例
2.4 決済取消権限のみを定める事例
3 本人が利用者登録をしていない場合における不正利用時の責任分担等に関する規定
4 賠償額の上限等
4.1 総論
4.2 賠償額の上限に関する事例
4.3 損害の種類による制限に関する事例
5 不正利用が行われた場合に備えて補償制度を設けている事例
5.1 補償制度の概要
5.2 補償制度に関する事例
5.3 補償規定に関する留意事項
(1) 一定の行為の要求
(2) 補償期間の限定
(3) 補償金額の限定
6 おわりに

 

なお、このガイドラインでは各種キャッシュレス決済サービスの名称などは記載されてなく、あくまで不正利用に対する補償の例をまとめたものになります。
経済産業省ではこのガイドラインを公開することで、キャッシュレス決済事業者の責任分担・補償等に関する規定を比較可能にすることで、サービス事業者に対して、消費者を意識することを促します。

www.meti.go.jp

 

金融分野の組織における個人情報の保護の考え方

金融分野の組織における個人情報保護の考え方を調べてみました。

 

金融分野における個人情報保護に関するガイドライン
https://www.fsa.go.jp/common/law/kj-hogo-2/01.pdf

金融分野における個人情報保護に関するガイドラインの安全管理措置等についての実務指針
https://www.fsa.go.jp/common/law/kj-hogo-2/03.pdf

 

www.fsa.go.jp

発行機関:金融庁
発行年月日:2018年2月

 

概要
金融庁では、「個人情報の保護に関する法律」の内容を踏まえ、金融分野の組織における個人情報保護のための指針を、「金融分野における個人情報保護に関するガイドライン 」として公開しています。

上記ガイドラインに記載のないものについては、個人情報保護委員会が公開している
「個人情報の保護に関する法律についてのガイドライン(通則編)」が適用されます。

https://www.ppc.go.jp/files/pdf/guidelines01.pdf

また、「金融分野における個人情報保護に関するガイドライン 」の中で、「~なければならない」と記載されている規定については、それに従わない場合、法の規定違反と判断される場合があります。

「金融分野における個人情報保護に関するガイドライン」章構成

第1条 目的等(法第1条関係)
第2条 利用目的の特定(法第 15 条関係)
第3条 同意の形式(法第 16 条、第 23 条及び第 24 条関係)
第4条 利用目的による制限(法第 16 条関係)
第5条 機微(センシティブ)情報
第6条 取得に際しての利用目的の通知等(法第 18 条関係)
第7条 データ内容の正確性の確保等(法第 19 条関係)
第8条 安全管理措置(法第 20 条関係)
第9条 従業者の監督(法第 21 条関係)
第 10 条 委託先の監督(法第 22 条関係)
第 11 条 第三者提供の制限(法第 23 条関係)
第 12 条 保有個人データに関する事項の公表等(法第 27 条関係)
第 13 条 開示(法第 28 条関係)
第 14 条 理由の説明(法第 31 条関係)
第 15 条 開示等の請求等に応じる手続(法第 32 条関係)
第 16 条 個人情報取扱事業者による苦情の処理(法第 35 条関係)
第 17 条 個人情報等の漏えい事案等への対応
第 18 条 個人情報保護宣言の策定(法第 18 条、第 27 条及び基本方針関係)
第 19 条 ガイドラインの見直し

第2条では個人情報の利用目的について、「自社の所要の目的で用いる」というような抽象的な表現ではなく、「当社の預金の受入れ」のような、より具体的な特定を求めています。
また、第4条では個人情報の利用に関して、本来の利用目的以外の用途(振り込め詐欺の被害にあった利用者の口座情報を警察に提供する、等)について指針を示しています。
第8条では、個人データの安全管理のため、基本方針や取扱規程の整備、安全管理措置の実施体制の整備を求めています。
安全管理措置は個人データの取得・利用・保管等の各段階における、「組織的安全管理措置」「人的安全管理措置」及び「技術的安全管理措置」に分類しています。

 

第8条第5項の規定内容

金融分野における個人情報取扱事業者は、個人データの安全管理に係る基本方針・取扱規程等の整備として、次に掲げる「組織的安全管理措置」を講じなければならない。
(組織的安全管理措置)
⑴ 規程等の整備
① 個人データの安全管理に係る基本方針の整備
② 個人データの安全管理に係る取扱規程の整備
③ 個人データの取扱状況の点検及び監査に係る規程の整備
④ 外部委託に係る規程の整備
⑵ 各管理段階における安全管理に係る取扱規程
① 取得・入力段階における取扱規程
② 利用・加工段階における取扱規程
③ 保管・保存段階における取扱規程
④ 移送・送信段階における取扱規程
⑤ 消去・廃棄段階における取扱規程
⑥ 漏えい事案等への対応の段階における取扱規程

第8条第6項の規定内容
金融分野における個人情報取扱事業者は、個人データの安全管理に係る実施体制の整備として、次に掲げる「組織的安全管理措置」、「人的安全管理措置」及び「技術的安全管理措置」を講じなければならない。
(組織的安全管理措置)
① 個人データの管理責任者等の設置
② 就業規則等における安全管理措置の整備
③ 個人データの安全管理に係る取扱規程に従った運用
④ 個人データの取扱状況を確認できる手段の整備
⑤ 個人データの取扱状況の点検及び監査体制の整備と実施
⑥ 漏えい事案等に対応する体制の整備
(人的安全管理措置)
① 従業者との個人データの非開示契約等の締結
② 従業者の役割・責任等の明確化
③ 従業者への安全管理措置の周知徹底、教育及び訓練
④ 従業者による個人データ管理手続の遵守状況の確認
(技術的安全管理措置)
① 個人データの利用者の識別及び認証
② 個人データの管理区分の設定及びアクセス制御
③ 個人データへのアクセス権限の管理
④ 個人データの漏えい・毀損等防止策
⑤ 個人データへのアクセスの記録及び分析
⑥ 個人データを取り扱う情報システムの稼働状況の記録及び分析
⑦ 個人データを取り扱う情報システムの監視及び監査

 

「金融分野における個人情報保護に関するガイドラインの安全管理措置等についての実務指針」では、上記の第8条に加えて、第9条「従業者の監督」、第10条「委託先の監督」について、具体的な指針を公開しています。

※「金融分野における個人情報保護に関するガイドライン」章構成の赤字部分

 

「金融業」とは

仮想通貨や、QRコード決済、インターネットバンキング等、「金融」の分野では色々なサービスが登場しています。

普段使っている「金融」という言葉に含まれる業務について調べてみました。

 

金融業とは

銀行、信用金庫、保険会社、証券会社など、貨幣の信用取引を行う業務。広義には貸金業も含めていうことがある。

dictionary.goo.ne.jp

 

銀行業について

一般的に銀行では以下の三大業務を行います。

預金業務
個人や企業を問わず、利用者から資金を預かるのが預金業務です。

融資業務
預金業務によって預かったお金を、資金を必要とする利用者へ貸出を行うことで資金の運用をする業務です。事業者に対する融資や、住宅ローンやマイカーローンなどの個人向けのローンなどがこれに含まれます。なお、貸したお金が返ってこなくなると銀行の経営は悪化します。これが「不良債権」です。

為替業務
利用者からの依頼によって他の口座に送金したり、利用者にかわって小切手や手形の代金を受け取る業務です。国内だけでなく外国へ送金するのも為替業務です。

上記は、銀行法で「固有業務」として規定されています。
固有業務以外に銀行が行っている業務のうち、銀行法で定められている業務を付随業務、銀行法に定めのないものを周辺業務と呼びます。

付随業務
付随業務には、債務保証、社債の募集・委託、手形引受け等の17の業務(銀行法10条2項)があります。

周辺業務
周辺業務とは、クレジットカード、リース、信用保証等の業務のことをいいます。
銀行法に定めのない周辺業務を、銀行は直接営むことができません。そのため、子会社を作って間接的に業務提供を行っています。
 

銀行の業務

固有業務(銀行の本業) 預金(受信業務)
貸付(与信業務)
為替(決済業務)
付随業務(銀行法10条) 債務保証、手形引受け、貸金庫など
周辺業務 クレジットカード、リース、ファクタリング

 

Lecture 1 銀行の主な業務 | 金融基礎講座 || 群馬銀行 新卒採用サイト

為替業務とは|金融経済用語集

https://www.findai.com/kouza/109fin.html

銀行・証券・保険・金融業界とは?仕事・業界研究 - リクナビ

 

銀行と似た組織として信用金庫があります。これらは、提供するサービスが似通っていても、経営理念や規模等がそれぞれ異なります。

 

「信用金庫」と「信用組合」「銀行」の主な相違点 

区分 信用金庫 信用組合 銀行
根拠法 信用金庫法

中小企業等協同組合法

協同組合による

金融事業に関する法律

(協金法)

銀行法
設立目的

国民大衆のために

金融の円滑を図り、

その貯蓄の増強に資する

組合員の相互扶助を目的とし、

組合員の経済的地位の向上を図る

国民経済の健全な発展に資する
組織

会員の出資による

協同組織の非営利法人

組合員の出資による

協同組織の非営利法人

株式会社組織の営利法人
会員(組合員)資格/td>

(地区内において)

住所または居所を有する者

事業所を有する者

勤労に従事する者

事業所を有する者の役員

<事業者の場合>

従業員300人以下または資本金9億円以下の事業者

(地区内において)

住所または居所を有する者

事業を行う小規模の事業者

勤労に従事する者

事業を行う小規模の

事業者の役員

<事業者の場合>

従業員300人以下または、

資本金3億円以下の事業者

(卸売業は100人または1億円、

小売業は50人または5千万円、

サービス業は100人または

5千万円)

なし
業務範囲 (預金・貸出金)

預金は制限なし

融資は原則として会員を対象とするが、制限つきで会員外貸出もできる(卒業生金融あり)

預金は原則として組合員を

対象とするが、総預金額の

20%まで員外預金が認められる

融資は原則として組合員を

対象とするが、制限つきで組合員でないものに貸出ができる

(卒業生金融なし)

制限なし

 

証券業について

証券業とは、銀行、信託会社その他政令で定める金融機関以外の者が次に掲げる行為の一つを行う営業をいう。(1)有価証券の売買,(2)有価証券の売買の媒介,取次ぎまたは代理,(3)有価証券市場における売買取引の委託の媒介,取次ぎまたは代理,(4)有価証券の引受け,(5)有価証券の売出し,(6)有価証券の募集または売出し(募集・売出し)の取扱い(証券取引法2条8項)。 (1)有価証券の売買とは,証券会社が自己の計算で顧客または他の証券会社から有価証券を買い,あるいは顧客等に対して有価証券を売却することをいう。

kotobank.jp

 

証券業の根拠法は金融商品取引法(金商法)となります。

elaws.e-gov.go.jp


証券会社の収益源泉は以下4つに大別できます。

<引受手数料収益>
企業が上場したり新たな株式を発行したりする場合に、その株式を証券会社が引き受け、これを投資家に売る際に手数料収益を得ます。

<株式・投信・債権売買委託料収益>
顧客である投資家から証券売買の注文を受け、株式や債券の売買を仲介して、この売買の委託料として収益を得ます。

<トレーディング収益>
証券会社が独自に持つ自己資金で、株式や債券の売買を行い収益を得ます。

<その他収益>
株式口座管理手数料や投信代行手数料、M&Aや財務に関するコンサルティングによるコーポレートアドバイザリー手数料など、手広く収益を得るポイントを設けています。

 

保険業について

保険加入者から保険料を収受し,保険事故が発生したときに保険金を所定の者に支払う事業をいう。なお保険事業という用語もあるが,これは経営形態によって国営保険事業,公営保険事業,私営または民営保険事業等に分かれ,内容によって社会保険事業,生命保険事業,損害保険事業に分かれる。保険業(狭義の保険事業)は,このうち民営の,生命保険事業または損害保険事業を指す。 民営の保険業は〈保険業法〉(1939公布。1995年に後述のように大幅改正)によって規制を受ける。

保険業の根拠法は保険業法となります。

elaws.e-gov.go.jp

 

保険会社のビジネスは二つの柱で成り立っています。

<保険領域>
生命保険会社と損害保険会社は様々な保険商品を開発し、保険への加入者(被保険者)を募集します。加入者は保険会社に保険料を支払い、この保険料が保険会社の収益になります。

<金融領域>
被保険者から保険料という形で集めた資金の一部を資産として運用し、収益を得ます。ここでいう「運用」は、株式や証券取引のことを指します。ただし、運用方法は保険業法と保険業法施行規則で細かく規定がなされています。
金融領域で得られた収益は、将来の保険金や配当金の財源にあてられることが主にになっています。

en-courage.com

 

「媒体のサニタイズに関するガイドライン」の概要

媒体のサニタイズに関するガイドライン

発行機関:NIST(IPA訳)
発行年月日:2006年9月

本文

SP 800-88, Guidelines for Media Sanitization | CSRC

和訳

https://www.ipa.go.jp/files/000025355.pdf

 

概要
情報システムは各種の媒体を使って情報を処理し、保存します。
上記の情報には保存することを意図されたものだけでなく、情報の処理や送信の過程でも保持されるものも含まれます。
このような残留情報が不正に開示されるリスクを軽減し、機密性を確保するためには媒体を適切な方法で処分する必要があります。
このガイドラインは、各組織が情報システムの機密性の分類を考慮しながら、適切なサニタイズと廃棄を行うことを支援するために策定されました。


情報の廃棄と媒体のサニタイズに関するポイントは、媒体の種類ではなく、記録されている情報の重要度にあります。
情報システムには、機密性の高い情報が含まれているものあり、重要度に応じ適切な処理を行わないと、不正な開示が発生する可能性があります。
そのため、このガイドラインは取り扱う情報に関して、適切な分類が行われていることを前提としています。

 

章構成

セクション 1では、この文書の作成機関、目的と範囲、対象読者、および前提条件について説明し、文書の構成を示す。
セクション 2 では、サニタイズに対するニーズの概要と、情報、サニタイズ、および媒体の基本的な種類の概要を示す。
セクション 3 では、サニタイズの意志決定を左右する手順と原則に関する一般的な情報を提供する。
セクション 4 では、サニタイズの意志決定を支援するプロセスの流れを示す。
セクション 5 では、いくつかの一般的なサニタイズ技法の要約を示す。
付録 A では、媒体のマトリックスを使って、各種の媒体を消去、除去、または破壊するために推奨される、最低限のサニタイズ技法を示す。この付録は、セクション 5 に示す意志決定フローチャートとともに使用すること。
付録 B では、このガイドで使用している用語の解説を示す。
付録 C では、媒体のサニタイズを支援するツールと参考になる外部情報源の一覧を示す。
付録 D では、組織のリソースにアクセスできないホームユーザや在宅勤務者向けの情報のサニタイズに関する考慮事項を示す。
付録 E では、このガイドの執筆に不可欠だった情報源や文書の一覧を示す。
付録 F では、組織のサニタイズ活動を文書化するための書式の例を示す。

 
サニタイズとは
データを簡単に取り出したり再現したりできないという合理的な保証を得るために記憶媒体からデータを削除するプロセスのことです。

 

サニタイズの種類 

種類 説明 技法
廃棄 サニタイズに関する特別な配慮を行わずに媒体を捨てる行為。機密ではない情報を含む古紙をリサイクルすることによって行われることが多いが、ほかの媒体を含む場合もある。  
消去 単にデータを削除するだけではなく、データの復旧ユーティリティによって情報を取り出すことができないようにする。たとえば、データの上書きは媒体の消去方法として容認できます。上書きが適切なサニタイズ方法かどうかは、媒体の種類やサイズに左右される場合もあります(SP 800-36 を参照)。また、研究の結果、今日の媒体のほとんどは1回上書きするだけで効果的に消去できるという結果が出ています。 媒体をサニタイズする方法の1つは、媒体上の格納領域を非機密データで上書きし、ファイルの論理的な格納場所(ファイルアロケー ションテーブルなど)の上書きだけでなく、アドレス指定可能なすべての場所の上書きが含まれる場合もあります。
除去 媒体を消去するだけでは十分ではない場合は、除去として消磁などの方法でデータを削除します。消磁は、破損した媒体の除去や、格納容量がきわめて大きい媒体の除去、フロッピーディスクの高速除去などに有効な方法です。媒体の除去が適当なサニタイズ方法でない場合は、媒体を破壊することが推奨されます。 除去の方法として、消磁やファームウェアのSecure Eraseコマンドの実行が挙げられます。
破壊 媒体の破壊は、一番のサニタイズ方法です。物理的な破壊は、分解、焼却、粉砕、細断、溶解などがあります。 分解、粉砕、溶解、および焼却等のサニタイズは、媒体を完全に破壊することを目的としており、専用の施設で実行されます。また、フロッピーディスクのような柔らかい媒体は細断という方法もあります。シュレッダを使って細断する場合、切るサイズは、データの機密性に応じて、そのデータを再現できないという十分な保証が得られる程度まで小さくします。

 

サニタイズと処分に関する意志決定に影響する要素

サニタイズに関する意志決定を行うときは、システムの機密性の分類とともに、いくつかの要素を考慮します。
たとえば、フロッピーディスクなどの安価な媒体を消磁するのは、費用対効果が高くない可能性があります。
サニタイズ方法の決定は、以下のような環境要因も考慮した上で、方法を決定することが望まれます。

  • 組織ではどのような種類(書き換え不可能な光ディスク、磁気ディスクなど)とサイズ(メガバイト、ギガバイト、テラバイトなど)の記憶媒体をサニタイズする必要があるか
  • 媒体に格納されているデータの機密性はどの程度か
  • 媒体は、管理された区域で処理されるか
  • サニタイズプロセスを組織内部と委託先のどちらで行うべきか
  • サニタイズする媒体の種類ごとの想定容量はどの程度か1
  • サニタイズ用の機器やツールの準備状況はどうか
  • サニタイズの機器/ツールに関する要員の訓練レベルはどうか
  • サニタイズにどのくらいの時間がかかるか
  • ツール、訓練、有効性の確認、および媒体を供給の流れに戻すことを考慮した場合、
  • どの種類のサニタイズのコストが高くなるか

 

f:id:iestudy:20190822231306p:plain

媒体のサニタイズおよび破棄に至る流れ

 

サニタイズに関わる責任の所在

最高情報責任者(CIO:Chief Information Officer)
CIOは、情報セキュリティポリシーを公布する責任を負います。情報の廃棄と媒体のサニタイズは、このポリシーの構成要素の1つで、CIOは、組織で行われるサニタイズが本文書のガイドラインに沿うようにする責任を負います。

 

情報オーナー
情報オーナー(≒情報の作成者)は、現場での媒体保守が適切に監督されていることの責任を負います。また、情報オーナーは、情報の利用者が情報の機密性と媒体のサニタイズの基本的な要件に沿うようにする責任も負います。

 

資産管理担当者
資産管理担当者は、サニタイズされた媒体や機器が組織内に再配布されたり、外部に寄付されたり、破壊されたりした場合に、それらの状況が適切に把握されていることを保証する責任を負います。