目次

ゼロトラストの原則は？

認証と認可が必要

リクエストごとの認証・認可

みなさんこんにちは。ユニリタ戌亥です。

時差ウォークはなんと90回になりました。
相変わらず、日の出を見るために早起きしておりますが、日の出時刻が遅くなってきたので、家を出る時間も同時に遅くなってきております。

コロナ奮闘記もこんなところまできました。

前回の最後に

「次回は当社が考えるゼロトラストについての概要についてお話ししましょう」

と締めくくったのですが、もう少しウンチクを話させてください。

実は、いろいろ調べていると、NISTという米国の有名な機関からゼロトラストに関するドキュメントが正式にリリースされていました。

(https://csrc.nist.gov/publications/detail/sp/800-207/final)

そうそう、あの、「90日に1回パスワード変更を強制せよ！」というガイドラインを作ったにもかかわらず、自ら「そんなのでけへんからやめた方がいいです」と数年前に撤回したところです。(NISTはNational Institute of Standards and Technologyの略)

■ ゼロトラストの原則は？

NISTによると、ゼロトラスト（Zero Trust、以降ZTという）とは

Zero trust security models assume that an attacker is present in the environment and that an enterprise-owned environment is no different—or no more trustworthy—than any non enterprise-owned environment.
ZTセキュリティモデルは、「脅威は会社が所有している環境にも会社が所有していない環境と同じだけ存在し信用できない」ということを想定しています。

と言っています。会社が所有している環境とは「Firewallの内側」のいわゆる社内LAN/WANのことです。

会社が所有していない環境とはクラウドやインターネットということです。

こんなことを書いている時に、ドコモ口座の件でテレビは大騒ぎです。

報道で聞いている限りでは、今までオフラインでやってきた引き落としの手続きをそのまま、インターネットでやってしまった感じですね。

オフラインでやっていた引き落としの手続きは、F/Wの内側で誰も悪い人がいない前提での手続き方法で、それをいきなりインターネットの世界に出してしまって大騒ぎしているような印象を受けました。

ZTで保護するものは、

In zero trust, these protections usually involve minimizing access to resources (such as data and compute resources and applications/services) to only those subjects and assets identified as needing access as well as continually authenticating and authorizing the identity and security posture of each access request.

ゼロトラストは、アクセスが必要であると認められた資産へのリソース（データ、コンピュータリソース、アプリケーション/サービス）に対して最小限のアクセスを行えるように保護をかけることであり、ID管理、セキュリティポリシー、リクエストごとの継続的な認証・認可などが含まれる。

とあります。

ドコモ口座の詳細をニュースで見た時に、認証と認可の仕組みがどうなっているのか心配になりました。

認証・認可はリソースの利用許可を与えるところがすべきです。ドコモがやっているから銀行側ではやらなくていいだろうというのは他者を信頼しすぎです。

ZTは境界で防御するのではなく、それぞれの情報資産に対して防御します。

Zero trust (ZT) provides a collection of concepts and ideas designed to minimize uncertainty in enforcing accurate, least privilege per-request access decisions in information systems and services in the face of a network viewed as compromised. Zero trust architecture (ZTA) is an enterprise’s cybersecurity plan that utilizes zero trust concepts and encompasses component relationships, workflow planning, and access policies. Therefore, a zero trust enterprise is the network infrastructure (physical and virtual) and operational policies that are in place for an enterprise as a product of a zero trust architecture plan
ZTはネットワークにさられた情報システムやサービスにおいて、リクエストごとのアクセスを正確に決定（許可）する上での不確実なところを最小限に抑えるために設計されたコンセプトやアイデアの集まりである。ZTAはゼロトラストのコンセプト、コンポーネントの関係、ワークフロー計画、アクセスポリシーを活用した、企業のサイバーセキュリティ計画である。したがって、ゼロトラストエンタープライズは、ゼロトラストアーキテクチャプランの製品としてエンタープライズに導入されているネットワークインフラストラクチャ（物理および仮想）と運用ポリシーである。

リクエストごとの認証と認可を確実に実行して、リスクを最小限に行うことがサイバーセキュリティ対策に必要であることがドキュメントに書かれております。

自慢になってしまいますが、弊社のネットワークインフラ「ユニリタFUN」では、認証しないとネットワークが使えない仕組みになっています。

「ユニリタFUN」の詳細は当コラムのバックナンバーをご覧ください。

Vol.1　コロナウイルスで世界が一変した…
（https://www.sysadmingroup.jp/col/vol-1）

Vol.4　SD-WANとゼロトラストアーキテクチャ(1)
（https://www.sysadmingroup.jp/col/vol-4）

「アクセスが必要であると認められた資産へのリソースに対して最小限のアクセスを行えるように保護をかける」

というのは「ユニリタFUN」のセキュリティコンセプトでもあります。

これをを実現させるために「ユニリタFUN」では、端末毎にアクセスできるVLANが定義されており、そのVLANによりアクセスできるリソースの塊をZoneという形で「マイクロセグメント」として定義しております。

「ユニリタFUN」は社内LANの中にもZTの要件をみたしており、マイクロセグメント単位でアクセスできるユーザーや端末を制限しております。

もう少しわかりやすい例でいうと、「経理の人しか使わない経理システム(群)はそれにアクセスしなければならない人のみがアクセスできるように制限をかけましょう」ということでする。

当社はメインフレームのビジネスがありますが、メインフレーム関連のリソース(サーバーやストレージ)にアクセスしなければならない人は、メインフレームの開発やサポートをしている人だけですので、クラウドの事業をしている人や経理業務をしている人はアクセスできないように制限をかけています。

■ 認証と認可が必要

上記を行うためには認証と認可が必要です。認証の対象は3つあります。

1つはUserです。

人間がログインして利用する時です。

2つ目は端末になります。

どの端末を使って利用しているか？です。

MAC認証や2段階認証などが利用できます。

そして3つ目はアプリケーションです。

システムにAPIを使ってアクセスする時には、① 誰の権限で、② どんなリソースにアクセスするのか？が必要です。

ゼロトラストを行うためには、認証・認可が必要であり、そしてその認証の強化が必要になります。

通常、認証の強化は多要素認証で行われます。

多要素認証とは2つ以上の要素(英語ではElementではなく、Factorと呼ばれている)を使って認証を行います。

要素１は本人しか知らないもの、要素２は本人しか持っていないはずのもの、この2つを使うのが一般的です。本人しか知らないもので一番有名なのはパスワードです。

パスワードが盗まれるとなりすまして入られてしまうので気をつけましょう。

本人しか持っていないものは、カードやスマホなどです。スマホにワンタイムパスワードを送ってくるのは2つ目の要素として使うためです。

もしも、本人しか持っていないはずのスマホが何人かで共有して使っていると、それはセキュリティとは言えなくなるので、自分のスマホを他人に貸すことはやめましょう。

■ リクエストごとの認証・認可

NISTのドキュメントではもう一つ重要なことが書かれております。

それは、上記で説明した認証と認可は「リクエストごとに行いなさい」、ということです。誰かがその本人になりすまし、認証をしない状態でリクエストを送る可能性があります。

その場合は「あなたは、どこのどなたですか？認証をしてからアクセスをしてください」と返します。

認証が済めば、その本人がアクセス可能かどうかをチェックします。

これが認可のプロトコルです。エンタープライズでは通常、セキュリティポリシーを作成して、誰がどのようなリソースにアクセスできるのか？を管理します。

リクエストごとの認証と認可をやると言っても、毎回のリクエストごとにユーザーIDとパスワードを求められると使いにくくてたまりません。

そのために、認証・認可のプロトコルはIT業界でデファクトスタンダードと呼ばれるプロトコルを定めております。

SAMLやOpenID Connect/OAuthと呼ばれているものがそれに当たります。

ゼロトラストを進めるためにはこのようなプロトコルに情報システムを対応させる必要があります。

次回はゼロトラストのアークテクチャの話をしたいと思います。