こんにちは！ネットワークやセキュリティの世界へようこそ。インフラの世界って、最初は専門用語が多くて「なんだか難しそう……」と感じてしまいますよね。でも、一歩ずつ身近な例に置き換えて見ていくと、実は私たちの日常とまったく同じ仕組みで動いていることが分かります。
今回は、最近の企業システムで耳にすることが増えた「SASE（サセ）」や「CASB（キャスブ）」という、ちょっとかっこいい名前のセキュリティ技術の中から、「SaaS利用のリスクスコアリング評価基準」についてお話しします。
「外部共有設定の有無」や「マルチファクタ認証の強制」といった言葉を、まるで郵便配達やマンションのオートロックシステムに例えながら、一緒に優しく紐解いていきましょう！
—
1. なぜ「SaaSの安全度」を測る必要があるの？
みなさんは普段、プライベートや仕事で、クラウド上のストレージやチャットツール（例えばGoogle WorkspaceやMicrosoft 365、Slackなど）を使っていますよね。会社支給のパソコンだけでなく、ときには自宅のPCやスマートフォンからアクセスすることもあるでしょう。
昔のオフィスは、会社の建物の中に頑丈な壁（ファイアウォール）を作って、「この中にいる人は安全、外の人は怪しい」という境界防御の考え方で成り立っていました。しかし、みんなが会社の外に出てクラウドサービスを直接使うようになった今、その古い壁だけでは会社の大切なデータを守りきれなくなっています。
ここで登場するのが、クラウドの利用を見守る門番であるCASB（Cloud Access Security Broker）です。CASBは、社員がどんなSaaSにアクセスしていて、そこでどんな危なっかしい使い方をしていないかを常に監視してくれています。
そのCASBが「このクラウドサービス、ちょっと危なっかしいぞ」と判断するために使っているのが、今回テーマにする「リスクスコアリング（安全性の数値化）」という仕組みです。
—
2. 郵便配達とマンションのオートロックで例えてみよう
リスクスコアリングの仕組みを、身近な「郵便配達」に例えて考えてみましょう。
あなたが大事な手紙（社外秘のデータ）を届けるとき、どんな配達先なら安心できますか？
- オートロック完備で、住人が誰か厳重に管理されているマンション（セキュリティがしっかりしたSaaS）
- 鍵がいつも開けっ放しで、誰でも自由に出入りできる空き家（野良アプリやセキュリティがガバガバなSaaS）
当然、後者のような場所には大事な手紙を置きたくないですよね。CASBのリスクスコアリングは、まさにこの「配達先の安全度」を0点から100点（あるいはA〜Eランク）で点数化する仕組みなんです。
具体的に、どんなポイントを見て点数を付けているのでしょうか？ 次の章で詳しく見ていきましょう！
—
3. リスクスコアリングを構成する「3つのチェックポイント」
CASBやSaaSの管理ツールが、クラウドサービスの安全性を評価するときにチェックしている主な基準は、大きく分けて次の3つです。
① 認証の厳しさ（誰でも入れるようになっていないか？）
- マルチファクタ認証（MFA）の強制： パスワードだけでなく、スマホの通知による承認や指紋認証など、2つ以上のステップを踏まないとログインできないようになっているか？
- シングルサインオン（SSO）の連携： 会社の厳格なID管理システムと繋がっているか？
② データの共有範囲（外へダダ漏れになっていないか？）
- 外部共有の許可設定： 保存したファイルが、URLを知っていれば世界中の誰でもアクセスできる「公開設定」になっていないか？
- ダウンロード制限： 個人のスマホや自宅のPCへのデータ保存が禁止されているか？
③ サービス自体の信頼性（提供元の企業は信用できるか？）
- コンプライアンスやセキュリティ認証： 国際的なセキュリティ基準（ISO/IEC 27001やSOC 2など）の監査を受けているか？
- 過去のインシデント履歴： 過去に大きな情報漏洩を起こしていないか？
これらを総合的に計算して、「このSaaSはリスクが高いから利用を禁止しよう」「この設定を変えてもらうまでデータは保存させないでおこう」と判断するわけです。
—
4. 実務での設定例をのぞいてみよう
「なるほど、考え方は分かったけれど、実際の現場ではどうやってそれを管理しているの？」気になりますよね。
例えば、API連携などを通じてSaaSのセキュリティ設定を自動でチェック・評価し、危険な状態を見つけたらSlackなどに通知を送るような自動化スクリプト（Pythonのイメージ）を考えてみましょう。実務ではこのようなコードや設定が裏側で動いています。
import requests
import json
# CASBやSaaSの管理APIのエンドポイント（模擬的なURL）
API_ENDPOINT = "https://api.example-casb.internal/v1/saas/risk-assessment"
HEADERS = {
"Authorization": "Bearer secret_api_token_12345",
"Content-Type": "application/json"
}
def evaluate_saas_risk(service_name, mfa_enabled, external_sharing_allowed):
"""
SaaSの利用状況からリスクスコア（100点満点中何点危ないか）を簡易算出する関数
"""
risk_score = 0
# 1. マルチファクタ認証が無効な場合はリスク大！ (+50点)
if not mfa_enabled:
print(f"[警告] {service_name}: マルチファクタ認証が無効です。")
risk_score += 50
# 2. 外部共有が許可されている場合はリスク中！ (+30点)
if external_sharing_allowed:
print(f"[警告] {service_name}: 誰でも見られる外部共有が許可されています。")
risk_score += 30
# リスクスコアに応じた判定
if risk_score >= 70:
status = "HIGH_RISK (利用禁止推奨)"
elif risk_score >= 40:
status = "MEDIUM_RISK (条件付き許可・要設定変更)"
else:
status = "LOW_RISK (安全)"
return {
"service": service_name,
"calculated_risk_score": risk_score,
"evaluation_status": status
}
# テストデータの検証（例：社員が勝手に使い始めた怪しいクラウドストレージ）
target_service = "Unsafe-Cloud-Storage"
result = evaluate_saas_risk(
service_name=target_service,
mfa_enabled=False, # MFAを設定していない
external_sharing_allowed=True # 誰でもリンクを知っていれば見られる
)
print(json.dumps(result, indent=4, ensure_ascii=False))このように、プログラムやCASBの自動機能を使って、「誰が・どんなサービスを・どんな設定で使っているか」を常に監視し、スコアが一定の基準を超えたらアラートを飛ばす、あるいは自動でアクセスを遮断する仕組みを作っているのです。
—
5. まとめ：安全と便利のバランスをとるために
今回は、SASEとCASBの重要な役割である「SaaS利用のリスクスコアリング評価基準」についてお話ししました。
- セキュリティ評価は、いわば「デジタル世界の配達先の安全チェック」。
- 「マルチファクタ認証の有無」や「外部共有の許可範囲」などを見極めて、サービス全体の危険度を数値化する。
- 現場のエンジニアは、APIや自動化ツールを使ってこのスコアリングを日々の運用に組み込んでいる。
セキュリティを高めすぎると、社員が仕事をしにくくなってしまいます（利便性の低下）。逆に、便利さだけを追求すると、いつの間にか会社の大切なデータが外へ漏れてしまうリスク（シャドーITの野放し）があります。
だからこそ、私たちエンジニアがリスクスコアリングの基準を正しく理解し、「どこまでが許容範囲で、どこからが危険なのか」を見極めるバランス感覚がとても大切なんです。
一歩ずつ、確実に知識を身につけて、頼られるインフラ・セキュリティエンジニアを目指していきましょう！
コメント