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