情報漏洩対策
ＭＤＭ　　　　デバイスのセキュリティに関する設定を制御
ＣＡＳＢ（キャスビー）
　　　　シャドーITの対策
　　　　クラウドに利用状況の可視化、野良クラウドの制限、データ保護
　　　　実装　　インライン型　通信全てを検査
　　　　プロキシと通信させる。端末にエージェントをインストールする必要がある
　　　　F／Ｗなどと連携させる　ゲートウェイのログを取得して可視化するので、

　　　　通信が制御できるのか？
　API型
　　　クラウドサービスの提供するAPIの活用　野良クラウドは可視化できない
　　　　　　　　　　　　　　　　　　　　　　　　　　　
　　　Saasの利用情報を可視化する技術・サービス
　　　ASaasへのアクセスは許可でもBSaasへはアクセス禁止とかする
　　　ビジネスチャットとかと連携させて、ファイルのアップロードを禁止したりする

EMM　　スマホなどのデバイスを細かく管理する技術
　　　　EMMで管理されたアプリがEMM対応のSaasを利用できる
　　　　EMMで管理されないアプリは、EMM対応のSaasを利用できない
IDaas（アイダース）
　　　　EMMに対応していないSaasへのアクセスを防ぐ
SGW（セキュリティゲートウェイ）
　　　　　PPAP対策
　　　　　添付ファイルを分離して、クラウドストレージにアップロードしてクラウドストレージの共有リンクを通知する
　　　　　メールの誤送信に気づいたら、共有を止める
　　　　　クラウドストレージのファイルを管理者がチェックすることも

　　　　　できる・・・・理論上では

ＩＤ管理
　　ID管理
　　　認証　　アクセスする利用者が、本人であることを確認する
　　　認可　　特定にシステムなどへアクセスを許可すること
　　　　
IDP　　IDを管理する　（ActiveDirectoryとか）
IDaaS　IDPをクラウド版
　　　　　主要機能
　　　　　ＩＤ管理
　　　　　ＩＤ連携
　　　　　認証
　　　　　認可

　　　　　認証に使われれるのは、「記憶」「所有物」「生体」
　　　　　多段階認証　複数回の認証をすること、種類は問わない
　　　　　多要素認証　必ず複数の認証を組み合わせるこ
　　　　　
生体認証を実現する規格
　FIDO2
　　事前に認証器で生体情報を登録（スマホとか）
　　登録結果をもとに。利用者のUIDと鍵ペア（秘密鍵と公開鍵）を作成し
　　UIDと公開鍵をIDPに登録　
　　passkey（パスキー）
　　シングルデバイス認証の場合
　　FIDOアライアンスが策定するWebアプリケーションのパスワードレス
認証仕様「WebAuthn」
　　スマホやパソコンでの生体認証などで本人確認を実施
　　「FIDO認証資格情報」とよばれる鍵を端末に生成
　　鍵を使って、ネットサービスのサーバ側とやりとりをする
　　問題点　端末の紛失・買い替え
　　　→マルチデバイス対応FIDO認証資格情報」　passkey
　　　　アップル　iCLOUDキーチェーン
　　　　google　　Google　Password　Manager
　　　　　　　
　IDの管理が重要　プロビジョニング（供給、支給、配置）の方法
　　Idaasのプロビジョニングの自動化
　　プロトコル　ＳＣＩＭ　
　　HTTPで利用者情報をやりとり、RESTAPIを経由して、ＪＳＯＮのフォーマットで送付する
　　新規IDは　HTTPのPOST、更新にpatch、削除はdeleteなど
　　　　　　　　　　
ActiveDirectoryのアクセス制御
　　ADはリソースへのアクセス権をセキュリティーグループ単位で設定する
　　ユーザアカウントが、ドメインコントローラにチケットを要求
　　ドメインコントローラは、認証して、チケットを払い出す
　　このチケットを提示して、リソースにアクセスする
　　　　　　　　
　　　　　　　　
　　異なるサービス間
　　　OAuth　異なるサービス間で使うプロトコル
　　　クライアントにアクセストークンを渡すためのオープンなプロトコル

ＳＳＯ（シングルサインオン）
　　IDAASで認証が出来たという結果をやりとりする
　　SAML　　　　　　利用者の同意を取る手順がない
　　OpenIDConnect　利用者の同意を取る手順が組み込まれている
　　　　　　　
　　Httpではアクセスチケットとして、cookieを使って状態を保持
　　サーバがクライアントにcookieを保存さえる場合、応答のSet-Cookieに情報を格納
　　クライアントが同じサーバにアクセスするときは、そのCookieを使う
　　Domain属性を使って、Cookieを送信するサーバのドメイン属性を指定する
　　省略時は、発行したサーバのホスト名が保存されます。（そのサーバだけCookieが送信される）
　　ドメインを設定することで、ドメイン配下のサーバにCookieを送付することが出来る
　　ドメイン属性は、後方一致なので、サブドメインも可能
　　Secure属性を付与することで、HTTPSで送付する
　　　　　　　
　　　　　　　
分散型ＩＤ
　　2022年7月　W3C
　　「Decentralized　Identifirs（DID)として公開
　　　ＤＩＤの構造
　　　スキーム
　　　DIDメソッド　DIDドキュメントを格納する　
　　　資格情報を発行して、秘密鍵は所有者が、公開鍵をドキュメントに記述
　　　DID固有の識別子　例　ビットコイン　btcr　　Webサイトならweb
　　　　　　　　　　
　　　DIDのドキュメントの場所は、DNSに似た「リゾルバー」を用いて解決する　　
　　　　　　　
　　　事業者の垣根を越えて利用可能な識別子　→今のところ、ブロックチェーン？
　　　　VC（検証可能な資格情報）をどうやって正しいとさせるか
　　　　ＶＣの構造　JSONまたはJSON-LD形式の文字列で作成
　　　　資格情報のメタデータ
　　　　対象ＩＤに関する表明
　　　　プルーフ（デジタル署名など）
　　　　　　　　　
　　イメージ
　　　　　卒業生の証明　大学側でIDなどを管理しておかないといけない
　　　　　卒業生が、在籍者である資格情報を持ち歩ける
　　　　　　　　　　　　　　　　
クラウド化
　クラウド活用に伴う通信トラフィックの増加などがあり、負荷対策が必要
　通信回線の帯域
　回線の遅延や揺らぎ
　サーバ同士の通信を見逃して、ベストエフォートで接続するなどすると問題が
　プロキシやF/Wのセッション数、NAPT
　Micorsoft365、GoogleWork-space
　端末一台あたり　20～30程度のセッション、最大100以上のときもある
　　　　　　　　　　　　
クラウドへの経路途中の負荷をオフロードする
　　ローカルブレイクアウト　　　　拠点側の手間
　　クラウドプロキシーの設置　　　ネットワークの構成は大きく変わらない
　　　データセンタへの回線に負荷が集中する対策にはならない
　　　クラウド接続サービスの利用　　通信コストが高いが安定
　　　　　　　　　　　　　
　　　　　　　　　　　
サーバの配置
　　オンプレで本番環境と開発環境が同じサブネットで混在している
　　クラウドに移行する場合は、役割が異なる資源別にサブネットを分割
　　クラウドでは、環境別にネットワークを細かく分ける
　　　　　　　　　
クラウドのF/W
　　ネットワークACL　サブネット単位で制御
　　セキュリティグループ　仮想サーバ単位で制御
　　推奨は、セキュリティグループ
　　　　　　　　　
　　　　　　　　　　　　　　
クラウドならではの仕様がある
　　暗黙のルータ（クラウドで仮想ネットワークを作ると自動生成される）
　　　大規模な環境になると発生
　　　　　　　接続数の問題
　　　　　　　アクセス回線の冗長化
　　従量課金
　　　クラウドサービスの課金は従量制のため、最適なネットワークを作成して余計なコストを抑える
　　　　　　　
Googleのメール送信ガイドライン
送信ドメイン認証のSPFまたはDKIMに対応する
送信ドメイン認証のSPFとDKIMの両方に対応する（5000件以上のメール送信者）
送信元のドメインまたはIPアドレスに、有効な正引き及び逆引きDNSレコードを

設定する
メールの送信にTLSを使用
受信者から報告される迷惑メールの割合を0.1%未満に保ち、0.3%を超えないようにする
　InternetMessageFormat標準に準拠する
　送信者アドレスをGmailのメールアドレスに偽装しない
　送信ドメイン認証のDMARCに対応する（5000件以上のメール送信者）
　DMARCをパスする
　（ヘッダーFromとエンベロープFromが同じ、あるいはDKIMの署名ドメインとヘッ
ダーfromが同じ）

（5000件以上のメール送信者）

ワンクリックで登録解除に対応し、メール本文に登録解除のリンクを分かりやすく表示する（5000件以上のメール送信者）
　
SPF　　

送信側が宣言したドメインから送られてきたかどうかを、DNSサーバで公開されているIPアドレスを使って検証する
　　　　　　記述ミス
　　　　　　　ip4をipv4と誤記
　　　　　　　　　　変にスペースを追加
　　　　　　　記述をシンプルに　
　　　　　　　DNSの参照が10回に制限されているので、それを超えるとエラーになる　　　
　　
DKIM　

送信側が宣言したドメインから送られてきたかどうかを、メールに付与された電子署名とDNSサーバで公開されている
　　　　　　公開鍵を使って検証する
DMARC　

　SPFやDKIMをパスしたドメインと送信者アドレス（ヘッダーFrom）を照合する。
　送信ドメイン認証に失敗したメールの処理方法（ポリシー）を送信側が指定する
SPF,DKIMの課題
　　認証に失敗しても運用上ではメールを受信するようにしている
　　送信者が全て対応しているわけでもなく、障害で認証が失敗したりするケースも

　　あるからヘッダーFromの詐称を見破れない
　　　　　
DMARK
　　認証に失敗したときの振る舞いを送信側が指定できる
　　ヘッダーFromのドメインを検証する
　　メーリングリスト・メールフィルタリングサービスを利用した場合に、

　　検証に失敗しやすい
　　エンベロープFromのメールアドレスを書き換えるためSPFのアライメントを

　　一致できない
　　外部メーリングサーバはややこしいが回避策を実装済み

　　　エンベロープFromを書き換えるから
　　　対応として、エンベロープFromもヘッダーfromもどちらも

　　　書き換えるようにして一致させる
　　　本来の差出人はCC:に追加するなどの対応をする
　　　　　　　　
　　　　　　　　
　　　　　　　　　
　　　　　
　　　　　
BIMI
　　BIMI対応クライアントで受信するとDMARCの認証に成功した場合、

　　送信元のブランドのロゴが表示され受信者が一目でわかる
　　BIMIに対応するには、送信側の企業のドメインとブランドのロゴとのひもつけ

　　「認証マーク証明書（VMC）」を取得する必要がある。

　　　VMCに第三者機関が発行する
　　　送信側の企業は、公開サーバにVMCとロゴをおく
　　　公開サーバのURLを含む「BIMIレコード」を送信ドメインを管理する

　　　DNSサーバに登録する
　　　DMARCまでの実施した受信メールサーバは、送信側のDNSサーバに

　　　BIMIレコードを問い合わせて取得
　　　受信メールサーバは、レコードからVMCとロゴデータをダウンロード
　　　　　VMCの有効性を確認
　　　　　メールを受信者に配信し、メールクライアントがロ号を表示する