01-2. CIA 三元組:機密性、完整性、可用性

深入理解資訊安全的三大核心原則

01-2. CIA 三元組:機密性、完整性、可用性

⏱️ 閱讀時間: 10 分鐘 🎯 難度: ⭐ (簡單) ⚠️ 提醒: 本文內容僅供學習與防禦用途


🎯 本篇重點

理解資訊安全的三大核心原則:機密性、完整性、可用性(CIA Triad),以及它們在 Web 應用中的實際應用。


🤔 什麼是 CIA 三元組?

CIA Triad = 資訊安全的三大核心原則

🔐 Confidentiality(機密性)
✅ Integrity(完整性)
⚡ Availability(可用性)

一句話解釋: CIA 三元組是資訊安全的基石,確保資料只被授權者看到(C)、未被竄改(I)、隨時可用(A)。


🔐 C - Confidentiality(機密性)

定義

確保資料只能被授權的人看到

機密性 = 保護秘密

目標:
- 防止未授權者存取資料
- 控制誰能看到什麼資料
- 保護敏感資訊

生活中的例子

🏠 實體世界:
├─ 保險箱(只有你有鑰匙)
├─ 密封的信件(只有收件人可拆)
└─ 醫療紀錄(只有醫生和病人能看)

💻 數位世界:
├─ 密碼(只有你知道)
├─ Email(只有收件人能讀)
└─ 銀行帳戶(只有你能查看餘額)

Web 應用中的機密性

需要保護的資料

👤 用戶資料:
├─ 密碼
├─ Email
├─ 電話號碼
├─ 地址
└─ 身份證字號

💳 金融資料:
├─ 信用卡號碼
├─ 銀行帳號
├─ 交易紀錄
└─ 收入資訊

🏢 商業資料:
├─ API 金鑰
├─ 資料庫密碼
├─ 商業機密
└─ 客戶名單

如何實現機密性?

# ✅ 正確:密碼加密儲存
from django.contrib.auth.hashers import make_password

def create_user(username, password):
    hashed_password = make_password(password)
    user = User.objects.create(
        username=username,
        password=hashed_password  # 儲存加密後的密碼
    )
    return user

# ❌ 錯誤:明文儲存密碼
def create_user_bad(username, password):
    user = User.objects.create(
        username=username,
        password=password  # 危險!明文儲存
    )
    return user
# ✅ 正確:HTTPS 傳輸敏感資料
# settings.py
SECURE_SSL_REDIRECT = True  # 強制使用 HTTPS
SESSION_COOKIE_SECURE = True  # Cookie 只能透過 HTTPS 傳輸
CSRF_COOKIE_SECURE = True

# ❌ 錯誤:HTTP 傳輸敏感資料
# 密碼、信用卡號碼透過 HTTP 傳輸
# → 任何人都能攔截並讀取
# ✅ 正確:存取控制
from django.contrib.auth.decorators import login_required

@login_required
def view_profile(request, user_id):
    # 確保用戶只能看自己的資料
    if request.user.id != user_id:
        return HttpResponseForbidden("無權存取")

    profile = Profile.objects.get(user_id=user_id)
    return render(request, 'profile.html', {'profile': profile})

# ❌ 錯誤:沒有存取控制
def view_profile_bad(request, user_id):
    # 任何人都能看任何用戶的資料
    profile = Profile.objects.get(user_id=user_id)
    return render(request, 'profile.html', {'profile': profile})

違反機密性的後果

真實案例:Yahoo(2013-2014)

違反:
- 30 億用戶資料外洩
- 密碼加密不足(MD5)
- 沒有啟用 HTTPS

後果:
💰 收購價格砍 3.5 億美元
⚖️ 集體訴訟
😰 用戶信任喪失

✅ I - Integrity(完整性)

定義

確保資料未被未授權竄改

完整性 = 資料可信賴

目標:
- 防止資料被篡改
- 偵測資料是否被修改
- 確保資料正確性

生活中的例子

🏠 實體世界:
├─ 封條(確認包裹未被打開)
├─ 簽名(確認文件未被偽造)
└─ 防偽標籤(確認產品真實)

💻 數位世界:
├─ 檔案校驗碼(MD5、SHA256)
├─ 數位簽章
└─ 版本控制(Git)

Web 應用中的完整性

需要保護的資料完整性

💰 金融交易:
├─ 轉帳金額(不能被改成更大金額)
├─ 收款帳號(不能被改成駭客帳號)
└─ 交易時間(不能被竄改)

📦 訂單資料:
├─ 商品價格(不能改成 $1)
├─ 收貨地址(不能被改成其他地址)
└─ 訂單狀態(不能偽造成「已出貨」)

👤 用戶資料:
├─ 權限等級(普通用戶不能改成管理員)
├─ 帳戶餘額
└─ 積分/點數

如何實現完整性?

# ✅ 正確:使用 CSRF Token 防止請求被篡改
from django.views.decorators.csrf import csrf_protect

@csrf_protect
def transfer_money(request):
    if request.method == 'POST':
        # Django 自動驗證 CSRF Token
        amount = request.POST.get('amount')
        to_account = request.POST.get('to_account')
        # 執行轉帳...
# ✅ 正確:使用資料庫交易確保完整性
from django.db import transaction

@transaction.atomic
def transfer_money(from_user, to_user, amount):
    # 所有操作要麼全部成功,要麼全部失敗
    from_account = Account.objects.select_for_update().get(user=from_user)
    to_account = Account.objects.select_for_update().get(user=to_user)

    if from_account.balance < amount:
        raise ValueError("餘額不足")

    from_account.balance -= amount
    to_account.balance += amount

    from_account.save()
    to_account.save()

    # 記錄交易日誌(不可竄改)
    Transaction.objects.create(
        from_user=from_user,
        to_user=to_user,
        amount=amount,
        timestamp=timezone.now()
    )
# ✅ 正確:驗證資料完整性
import hashlib

def verify_file_integrity(file_path, expected_hash):
    """驗證檔案是否被竄改"""
    sha256_hash = hashlib.sha256()
    with open(file_path, "rb") as f:
        for byte_block in iter(lambda: f.read(4096), b""):
            sha256_hash.update(byte_block)

    actual_hash = sha256_hash.hexdigest()

    if actual_hash != expected_hash:
        raise ValueError("檔案已被竄改!")

    return True
# ❌ 錯誤:允許客戶端控制價格
def create_order(request):
    product_id = request.POST.get('product_id')
    price = request.POST.get('price')  # 危險!客戶端可傳 price=1

    order = Order.objects.create(
        product_id=product_id,
        price=price  # 應該從資料庫取得,不是客戶端
    )

# ✅ 正確:從伺服器端取得價格
def create_order_secure(request):
    product_id = request.POST.get('product_id')
    product = Product.objects.get(id=product_id)

    order = Order.objects.create(
        product=product,
        price=product.price  # 從資料庫取得正確價格
    )

違反完整性的後果

真實案例:Steam(2015)

違反:
- 客戶端可修改購物車價格
- 用 $0.01 購買遊戲

原因:
- 價格驗證在客戶端進行
- 伺服器端未重新驗證

後果:
- 緊急修補漏洞
- 大量訂單作廢
- 商譽受損

⚡ A - Availability(可用性)

定義

確保系統隨時可用,授權用戶能正常存取

可用性 = 服務不中斷

目標:
- 防止服務被癱瘓
- 確保系統正常運作
- 快速恢復故障

生活中的例子

🏠 實體世界:
├─ 24 小時便利商店(隨時營業)
├─ 緊急出口(火災時必須可用)
└─ 備用電源(停電時繼續供電)

💻 數位世界:
├─ Google(幾乎不當機)
├─ ATM(24 小時服務)
└─ 醫院系統(不能中斷)

Web 應用中的可用性

威脅可用性的攻擊

💥 DDoS 攻擊(分散式阻斷服務攻擊)
├─ 大量假請求癱瘓伺服器
├─ 合法用戶無法使用服務
└─ 範例:每秒百萬次請求

🐌 資源耗盡攻擊
├─ Slowloris(慢速連線攻擊)
├─ ZIP 炸彈(解壓縮耗盡硬碟)
└─ 正則表達式 DoS(ReDoS)

🔐 勒索軟體
├─ 加密所有檔案
├─ 要求贖金才解密
└─ 服務完全無法使用

如何實現可用性?

# ✅ 正確:限制請求頻率(Rate Limiting)
from django.core.cache import cache
from django.http import HttpResponseTooManyRequests

def rate_limit(request):
    ip = request.META.get('REMOTE_ADDR')
    key = f'rate_limit_{ip}'

    # 取得該 IP 的請求次數
    count = cache.get(key, 0)

    if count > 100:  # 1 分鐘內超過 100 次請求
        return HttpResponseTooManyRequests("請求過於頻繁,請稍後再試")

    # 增加計數
    cache.set(key, count + 1, 60)  # 60 秒後過期

    return None
# ✅ 正確:使用 Connection Pool 避免資源耗盡
# settings.py
DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.postgresql',
        'CONN_MAX_AGE': 60,  # 連線池:重複使用連線
        'OPTIONS': {
            'connect_timeout': 10,
            'options': '-c statement_timeout=30000'  # 30 秒超時
        }
    }
}
# ✅ 正確:設定超時避免資源卡死
import requests

def fetch_external_api():
    try:
        response = requests.get(
            'https://api.example.com/data',
            timeout=5  # 5 秒超時
        )
        return response.json()
    except requests.Timeout:
        return {"error": "API 超時"}
# ✅ 正確:備份與災難恢復
# 1. 定期備份資料庫
# cron job: 0 2 * * * /backup/db_backup.sh

# 2. 多個副本(Replica)
DATABASES = {
    'default': {
        # 主資料庫
    },
    'replica': {
        # 唯讀副本,分散讀取壓力
    }
}

# 3. CDN 分散流量
# 靜態檔案透過 CDN 服務(如 Cloudflare)
# ❌ 錯誤:沒有限制查詢大小
def search(request):
    query = request.GET.get('q')
    # 如果 query 很複雜,可能拖垮資料庫
    results = Product.objects.filter(name__icontains=query)
    return render(request, 'search.html', {'results': results})

# ✅ 正確:限制查詢結果數量
def search_secure(request):
    query = request.GET.get('q', '')

    # 限制查詢長度
    if len(query) > 100:
        return HttpResponseBadRequest("查詢字串過長")

    # 限制結果數量
    results = Product.objects.filter(name__icontains=query)[:100]
    return render(request, 'search.html', {'results': results})

違反可用性的後果

真實案例:GitHub(2018)

攻擊:
- 史上最大 DDoS 攻擊
- 1.35 Tbps 流量(每秒 1.35 兆位元)
- Memcached 反射放大攻擊

後果:
- 服務中斷 10 分鐘
- 全球開發者無法存取
- 緊急啟用 DDoS 防護

應對:
✅ Cloudflare DDoS 防護
✅ 流量清洗
✅ 快速恢復服務

🔄 CIA 三者的平衡

三者關係

         機密性
         🔐
        /  \
       /    \
      /      \
     /        \
完整性 ◀────▶ 可用性
  ✅           ⚡

平衡點:
- 過度強調機密性 → 可能影響可用性
- 過度強調可用性 → 可能犧牲機密性
- 需要根據業務需求平衡三者

實際案例

案例 1:銀行系統

優先順序:機密性 ≥ 完整性 > 可用性

🔐 機密性(最高優先):
├─ 用戶密碼絕對保密
├─ 交易紀錄加密
└─ 強制使用 2FA

✅ 完整性(非常重要):
├─ 轉帳金額不能錯
├─ 帳戶餘額必須正確
└─ 交易紀錄不可竄改

⚡ 可用性(重要但可犧牲):
├─ 可以暫時當機維護
├─ 寧可拒絕可疑交易
└─ 異常時自動鎖定帳戶

結論:
寧可服務暫時不可用,也不能讓資料外洩或錯誤

案例 2:社群媒體

優先順序:可用性 > 機密性 > 完整性

⚡ 可用性(最高優先):
├─ 必須 24/7 運作
├─ 快速載入
└─ 全球都能使用

🔐 機密性(重要):
├─ 保護私訊
├─ 密碼加密
└─ 隱私設定

✅ 完整性(相對低優先):
├─ 貼文讚數可能有延遲
├─ 留言順序可能不精確
└─ 可接受最終一致性

結論:
用戶最在意能否使用,資料延遲可接受

案例 3:醫療系統

優先順序:可用性 ≥ 完整性 ≥ 機密性

⚡ 可用性(最高優先):
├─ 緊急情況不能當機
├─ 醫生必須立即存取病歷
└─ 生命第一

✅ 完整性(極高優先):
├─ 病歷不能錯誤
├─ 藥物劑量必須精確
└─ 檢查報告不能竄改

🔐 機密性(高優先但可權衡):
├─ 緊急時醫生可存取病歷
├─ 救命優先於隱私
└─ 事後記錄存取日誌

結論:
生命第一,但必須確保資料正確

📊 CIA 實戰檢查清單

機密性檢查

✅ 密碼有加密儲存?(Bcrypt、Argon2)
✅ 敏感資料有加密?(AES-256)
✅ 使用 HTTPS 傳輸?
✅ API 金鑰有保護?(環境變數)
✅ 日誌沒有記錄密碼?
✅ 有存取控制?(誰能看什麼)
✅ Session/Token 有保護?(HttpOnly)

完整性檢查

✅ 有 CSRF 保護?
✅ 有輸入驗證?
✅ 價格從伺服器取得?(不信任客戶端)
✅ 有使用資料庫交易?
✅ 重要操作有日誌記錄?
✅ 有檔案校驗碼?(SHA-256)
✅ 有數位簽章?

可用性檢查

✅ 有 Rate Limiting?
✅ 有設定超時時間?
✅ 有錯誤處理?(不會 crash)
✅ 有負載平衡?
✅ 有資料庫備份?
✅ 有監控與告警?
✅ 有災難恢復計畫?

🎓 面試常考題

Q1:什麼是 CIA 三元組?

A:資訊安全的三大核心原則

🔐 Confidentiality(機密性)
→ 確保資料只能被授權者看到
→ 範例:密碼加密、HTTPS

✅ Integrity(完整性)
→ 確保資料未被未授權竄改
→ 範例:CSRF Token、數位簽章

⚡ Availability(可用性)
→ 確保系統隨時可用
→ 範例:Rate Limiting、備份

記憶口訣:「秘密完整用得到」

Q2:HTTPS 主要保護 CIA 的哪一項?

A:主要保護機密性(Confidentiality)

原因:
✅ 加密傳輸內容(機密性)
✅ 防止中間人攻擊(完整性)
✅ 但無法防止 DDoS(可用性)

完整答案:
HTTPS 同時保護機密性與完整性,
但對可用性的保護有限。

Q3:如何在 Django 確保密碼的機密性?

A使用 Django 內建的密碼哈希系統

# ✅ 正確做法
from django.contrib.auth.models import User
from django.contrib.auth.hashers import make_password, check_password

# 儲存密碼
user = User.objects.create_user(
    username='john',
    password='secret123'  # Django 自動哈希
)

# 驗證密碼
from django.contrib.auth import authenticate
user = authenticate(username='john', password='secret123')

# Django 預設使用 PBKDF2 + SHA256
# settings.py 可設定:
PASSWORD_HASHERS = [
    'django.contrib.auth.hashers.Argon2PasswordHasher',  # 更安全
    'django.contrib.auth.hashers.PBKDF2PasswordHasher',
]

✅ 重點回顧

CIA 三元組定義:

  • 🔐 機密性(Confidentiality):確保資料只能被授權者看到
  • 完整性(Integrity):確保資料未被未授權竄改
  • 可用性(Availability):確保系統隨時可用

實現方法:

  • 機密性:加密、HTTPS、存取控制
  • 完整性:CSRF Token、數位簽章、交易機制
  • 可用性:Rate Limiting、備份、監控

三者平衡:

  • 銀行:機密性 > 完整性 > 可用性
  • 社群:可用性 > 機密性 > 完整性
  • 醫療:可用性 ≥ 完整性 ≥ 機密性

檢查清單:

  • ✅ 密碼加密?HTTPS?存取控制?(機密性)
  • ✅ CSRF 保護?輸入驗證?日誌記錄?(完整性)
  • ✅ Rate Limiting?超時設定?備份?(可用性)

記憶口訣: 「秘密完整用得到」= 機密性、完整性、可用性


上一篇: 01-1. 什麼是 Web 資安? 下一篇: 01-3. 常見攻擊類型概覽


最後更新:2025-01-16

0%