- ライター：渥美 淳一
- セキュリティアーキテクトとして活動。変革し続けるニーズからセキュリティのあるべき姿を見極める。セキュリティには統合されたアイデンティティ基盤が欠かせないと考えている。
目次
はじめに
NPO 日本ネットワークセキュリティ協会主催のウェビナーに登壇しました。
本ブログはこちらのウェビナーをコンパクトにまとめたものです。弊社セキュリティアーキテクトによるネットワークセキュリティへのアプローチをご紹介します。
上司にネットワークセキュリティの強化を命じられたら？
まずセキュリティ機能の集約を検討します。これにより、どこからアクセスしてもセキュリティポリシーを統一できます。さらに運用、監視するポイントを一か所にまとめて負荷を軽減します。例えば、拠点やクラウドなどを「ハブ」と「スポーク」に分けます。そして次世代ファイアウォールなどのセキュリティ機能をハブに集約します。スポークとなる拠点から保護したいリソースへのアクセスは、必ずハブを経由するよう設計します。これまではデータセンターがハブ役を担当していました。しかし将来の拡張性などを考慮し、AWS や Azure にハブを構築することを検討します。
ただ、ハブに設置したセキュリティ製品のアップデート、脆弱性対策などの運用負荷が懸念されます。そこで、SaaS 型のセキュリティサービス（SASE など）をハブにすることを検討します。アップデートや脆弱性対策などの運用負荷を委任する目的です。
次に、従業員のリモートワークのためのネットワークセキュリティを検討します。自宅などから組織内にあるリソースにアクセスする手段として、VPN や VDI が候補に挙がります。それらもアップデートや脆弱性対策を考慮しなければなりません。コストがかかりますし、最新の脆弱性をリアルタイムに把握し続けることも簡単ではありません。また通信の遅延など、パフォーマンスを損なうと従業員のストレスになります。そのためにオーバースペックな VPN 装置などを導入しますと、コストが無駄になる可能性があります。そこで、こちらも同様に SaaS 型セキュリティサービスを検討します。
どこからでもアクセスでき、アップデートや脆弱性対策などのトータルサポートを委任できます。かつ、遅延が少なく、ボトルネックのない高パフォーマンスなネットワークを提供できます。買収によるセキュリティベンダーの統廃合が進んでいることもセキュリティ集約の追い風になっています。
ネットワークとアイデンティティの関係は？
以前は、データセンターを中心にネットワークやセキュリティが構成されていました。働く場所も、攻撃対象領域も把握できたため、境界防御や内部脅威対応が効果的でした。しかし通信が暗号化され、そこに脅威が潜むようになりました。高度化し続ける脅威の検知に時間を要するようになりました。クラウドファーストになってトラフィックやセッション数が増え、攻撃対象領域も拡大しました。それに伴い、データセンターのネットワークとセキュリティが悲鳴をあげるようになりました。さらにコロナ禍により、リモートワークが重視されるようになりました。働く場所も、攻撃対象領域も、把握しきれなくなりました。境界防御や内部脅威対応だけでは保護しきれなくなりました。
そこで、セキュリティを SaaS 型セキュリティサービスに集約することを検討します。セキュリティポリシーの統一、運用負荷の軽減、将来を見据えたパフォーマンスの維持が目的です。正しい従業員であれば、どこからでも接続でき、セキュリティが担保され、リソースへアクセスできます。
では、実はこれが正しい従業員じゃなかったとしたら、どうなるでしょうか？
正しい従業員の ID とパスワードが盗まれ、なりすましてアクセスされた場合は？
その場合のダメージは計り知れません。このアプローチで重要なのは、接続前に正しい従業員であることを徹底検証することです。パスワードに依存せず、より堅牢で、かつユーザー体験を損なわない認証が望ましいです。
そこでアイデンティティセキュリティの検討が推奨されます。例えば Salesforce や GitHub など、アプリケーション側では二要素認証の導入が進められています。これをネットワークでも検討すべきです。正しい従業員であることを徹底検証してから接続を許可しましょう。
それに秀でたアイデンティティセキュリティサービスが「IDaaS」です。多要素認証やパスワードレス認証、さらにはデバイス認証やリスクベース認証も組み合わせて当人認証できます。強化された認証に合格すれば、ネットワーク接続、そしてアプリケーションへのシングルサインオンが可能です。正しい従業員であっても所属部署や役職に応じて特定のアプリケーションを利用させないように制限することもできます。退職などで正しい従業員ではなくなったら自動的に無効化され、ネットワークもアプリケーションも利用させません。
こうしてネットワークの「隙」「弱点」を減らし、セキュリティポリシーや従業員の管理を効率よく実施します。
具体的に何がどう変わる？
例えば Web プロキシサーバーをクラウドに移行します。
以前はデータセンターに展開された Web プロキシサーバーに Web トラフィックを集約していました。働く場所が自宅だった場合、その Web プロキシサーバーを経由するためにデータセンターへの VPN 接続が必要です。VPN 接続時、ログイン画面になり、正しい従業員であることを検証されます。VPN 接続後、インターネットへ Web アクセスしますと、今度は Web プロキシサーバーに検証されます。正しい従業員であることが検証された後、Web アクセスが可能になります。さらにアクセス先の Web アプリケーションへのログインが要求されます。こうしてログイン地獄を経て、正しい従業員だけが適切にリソースアクセスできる環境を実現していました。
このログイン地獄から逃れるべく、Web プロキシサーバーのクラウド移行と同時に SAML 認証連携を採用します。これにより、正しい従業員であることの検証（認証）をすべて IDaaS に任せることができます。
まず、クラウドの Web プロキシから最新の PAC ファイルを自動取得できます。インターネットへ Web アクセスしますと、PAC ファイルに従ってクラウドの Web プロキシに接続しようとします。このとき正しい従業員か否か？が未検証だった場合、SAML 認証連携によって強制的に IDaaS へリダイレクトされます。そして正しい従業員か否か？を多要素認証、パスワードレス認証、デバイス認証などにより徹底検証されます。組織ドメインにログイン済みであれば「正しい従業員として認証済み、ログイン不要」とすることができます。（統合 Windows 認証）
ここで IDaaS が正しい従業員と認めなければ、クラウドの Web プロキシ接続前にブロックされます。IDaaS は正しい従業員にのみ、許可証（SAML アサーション）を発行します。許可証には、その従業員に関する情報が含まれます。正しい従業員は、その許可証をクラウドの Web プロキシに提出します。クラウドの Web プロキシはその許可証により、従業員の識別やアクセス制御が可能となります。
こうして IDaaS に許可された正しい従業員のみ、クラウドの Web プロキシを通過できるようになります。さらに通過するには脅威防御、URL フィルタリング、サンドボックス等のセキュリティチェックに合格する必要がありますが、合格すればその先の Web アプリケーションも同じ IDaaS と SAML 認証連携することでログイン不要になります。
結果、移行後も高度なセキュリティを実装し、課題だったログイン地獄からも抜け出すことができます。
最後に
保護すべきリソースがオンプレミスやクラウドに分散し、ネットワーク経路もバラバラになりがちです。ネットワークのセキュリティは、まず「集約」を、次に「見える化」を検討しましょう。そのためには HTTPS（TLS 1.3 以降）を復号でき、パフォーマンスを損なわないことが不可欠です。見える化により、どこからのアクセスか？はもちろん、誰からのアクセスか？も見極めることができます。どのアプリケーションへのアクセスか？を識別できれば、シャドー IT の規制も可能です。
とはいえ、増え続けるトラフィックをすべて見える化し続けるのは大変な負荷です。そこで、つなぐ前に本人確認を徹底し、正しい従業員のトラフィックのみにしましょう。不正なトラフィックを減らす意味でも、正しい従業員のみ許可するアイデンティティセキュリティを検討しましょう。
いちばん怖いのは、正しい従業員の ID が乗っ取られることです。IDaaS は誰でもどこからでもアクセスできるネットワークの窓口となり、ID を保護できるクラウドサービスです。つなぐ前に IDaaS へ強制リダイレクトする SAML などの認証連携プロトコルもセキュリティ対策のひとつです。ユーザー体験を損なわずに、アイデンティティとネットワークの多層防御を可能にします。さらに内部不正対策として、正しい従業員に付与する権限を必要最小限にするアプローチへと続きます。これが結果的にゼロトラストの実装につながります。
ゼロトラストの実装はセキュリティ強化が目的ですが、組織の成長のためでもある、と考えます。今の時代のセキュリティのあり方を意識し、研鑽するキッカケになるからです。組織の成長は従業員の成長につながり、また働きやすさ、やりがいを生み出します。
「うちの IT 環境は最高！」
「ここで働けてよかった！」
誰もがそう思える未来を、新しいセキュリティでたぐり寄せましょう。
※本記事の内容は執筆者個人の見解であり、所属する組織の見解を代表するものではありません。
