Self-Host AI Security

ทำไม Self-Host AI ต้องดูแลเรื่อง Security?

เมื่อคุณ รัน Ollama บนเครื่องตัวเอง ข้อมูลทั้งหมดอยู่ในเครือข่ายองค์กร ซึ่งเป็นข้อดีด้าน Privacy แต่ถ้าตั้งค่าไม่ดี อาจกลายเป็นช่องโหว่ใหญ่ได้ เพราะ Ollama ออกแบบมาให้ใช้งานง่าย (Developer-friendly) มากกว่าจะเน้น ความปลอดภัย ตั้งแต่แรก ผลลัพธ์คือ ค่า Default ไม่มีการป้องกันใดๆ เลย:

ความเสี่ยง	สาเหตุ	ผลกระทบ	วิธีแก้
ไม่มี Authentication	Ollama ไม่มี Auth ในตัว	ใครก็เรียกใช้ AI ได้ ใช้ GPU ฟรี	เพิ่ม Auth Layer ผ่าน Reverse Proxy
ไม่มี TLS/HTTPS	API ส่งข้อมูลแบบ Plain Text	ข้อมูลถูก Sniff ระหว่างทาง	ตั้ง TLS Certificate ผ่าน nginx/Caddy
ไม่มี Rate Limit	ไม่จำกัดจำนวน Request	Server ล่มจาก Request ท่วม / GPU 100%	ตั้ง Rate Limit ใน nginx
เปิด Port สู่เครือข่าย	ตั้ง OLLAMA_HOST=0.0.0.0	ทุกเครื่องในเครือข่ายเข้าถึงได้	Bind localhost + Firewall
ไม่มี Monitoring	ไม่มี Log / Alert	ไม่รู้ว่าใครใช้ ใช้เมื่อไหร่ ใช้เท่าไหร่	ตั้ง Access Log + Prometheus

จากสถิติ Shodan (เครื่องมือค้นหาอุปกรณ์ที่เปิดสู่ Internet) พบ Ollama Server กว่า 7,000+ เครื่องทั่วโลก ที่เปิด Port 11434 สู่ Internet โดยไม่มี Authentication ซึ่งหมายความว่าใครก็ได้สามารถใช้ GPU ของเครื่องเหล่านั้นรัน AI ได้ฟรี หรือแม้กระทั่งดาวน์โหลด/ลบ Model ออกจากเครื่องได้ เรื่องนี้เป็นปัญหาเดียวกับที่เราเคยพูดถึงในบทความ Two-Factor Authentication ว่าแค่รหัสผ่านอย่างเดียวยังไม่พอ ต้องมีหลายชั้นป้องกัน

Checklist 10 ข้อ — Secure Ollama Self-Host

ก่อนจะลงรายละเอียดแต่ละข้อ มาดู Checklist ภาพรวมกันก่อน:

#	รายการ	ความสำคัญ	รายละเอียด
1	Bind localhost only	สูงมาก	ตั้ง OLLAMA_HOST=127.0.0.1 ไม่เปิดให้เครือข่ายเข้าตรง
2	Reverse Proxy + TLS	สูงมาก	ใช้ nginx/Caddy + SSL Certificate เข้ารหัสทุก Request
3	Authentication	สูงมาก	เพิ่ม Basic Auth / API Key / OAuth ยืนยันตัวตนก่อนเข้าถึง
4	Firewall Rules	สูงมาก	ใช้ ufw/iptables เปิดเฉพาะ Port ที่จำเป็น
5	Docker Isolation	สูง	รันใน Container จำกัด Memory/CPU ไม่กระทบ Host
6	Rate Limiting	สูง	จำกัด Request/วินาที ป้องกัน Abuse และ DDoS
7	Network Segmentation	สูง	แยก VLAN / ใช้ VPN สำหรับเครื่องที่ต้องเข้าถึง AI
8	Logging & Monitoring	สูง	เก็บ Access Log + Prometheus/Grafana ดู Metrics
9	Regular Updates	ปานกลาง	รัน ollama update สม่ำเสมอ รับ Patch ความปลอดภัย
10	Backup Model Data	ปานกลาง	สำรองข้อมูล Model + Modelfile เป็นประจำ

Reverse Proxy + TLS — ตั้งค่า nginx

แทนที่จะเปิด Ollama Port 11434 ให้เครื่องอื่นเข้าตรง ให้ใช้ nginx เป็นตัวกลาง (Reverse Proxy) แล้วเพิ่ม SSL Certificate เพื่อเข้ารหัสการสื่อสาร:

# /etc/nginx/sites-available/ollama.conf

upstream ollama {
    server 127.0.0.1:11434;
}

server {
    listen 443 ssl http2;
    server_name ai.yourcompany.com;

    # SSL Certificate (Let's Encrypt / Internal CA)
    ssl_certificate     /etc/ssl/certs/ollama.crt;
    ssl_certificate_key /etc/ssl/private/ollama.key;
    ssl_protocols       TLSv1.2 TLSv1.3;
    ssl_ciphers         HIGH:!aNULL:!MD5;

    # Basic Authentication
    auth_basic           "Ollama AI - Authorized Only";
    auth_basic_user_file /etc/nginx/.htpasswd;

    # Rate Limiting (defined in http block)
    limit_req zone=ollama_limit burst=5 nodelay;

    # Proxy to Ollama
    location / {
        proxy_pass http://ollama;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;

        # Timeout สำหรับ AI (Model ใหญ่อาจใช้เวลานาน)
        proxy_read_timeout 300s;
        proxy_send_timeout 300s;

        # Streaming support
        proxy_buffering off;
        chunked_transfer_encoding on;
    }

    # Block sensitive endpoints
    location /api/delete {
        deny all;
        return 403;
    }

    location /api/pull {
        deny all;
        return 403;
    }

    # Access Log
    access_log /var/log/nginx/ollama_access.log;
    error_log  /var/log/nginx/ollama_error.log;
}

# Redirect HTTP to HTTPS
server {
    listen 80;
    server_name ai.yourcompany.com;
    return 301 https://$server_name$request_uri;
}

Config นี้ทำ 5 อย่างพร้อมกัน: (1) เข้ารหัส HTTPS, (2) ยืนยันตัวตน Basic Auth, (3) จำกัด Rate, (4) บล็อก Endpoint อันตราย (ลบ/ดาวน์โหลด Model), (5) เก็บ Log ทุก Request

Authentication — เพิ่ม Auth Layer

เนื่องจาก Ollama ไม่มี Authentication ในตัว เราต้องเพิ่มเองผ่าน Reverse Proxy มี 3 วิธีหลัก แต่ละวิธีเหมาะกับสถานการณ์ต่างกัน (คล้ายหลักการ Digital Signature ที่ต้องยืนยันตัวตนก่อนเข้าถึง):

วิธี	ความยากในการตั้งค่า	เหมาะกับ	ข้อดี	ข้อเสีย
Basic Auth	ง่าย	ทีมเล็ก 2-10 คน	ตั้งค่าเร็ว ใช้กับ nginx ได้ทันที	จัดการ User ยาก, ไม่มี Token Expiry
API Key Header	ปานกลาง	แอป/Service เรียกใช้ API	เหมาะกับ M2M, เปลี่ยน Key ง่าย	ต้องเขียน Lua/Config เพิ่ม
OAuth2 Proxy	ยาก	องค์กรใหญ่ มี SSO/LDAP	ผสมกับ SSO, Token Expiry, RBAC	ตั้งค่าซับซ้อน ต้องมี IdP

ตัวอย่าง: ตั้งค่า Basic Auth

# สร้างไฟล์ Password (ต้องติดตั้ง apache2-utils)
sudo apt install apache2-utils

# สร้าง User คนแรก (-c สร้างไฟล์ใหม่)
sudo htpasswd -c /etc/nginx/.htpasswd ai_user1

# เพิ่ม User เพิ่มเติม (ไม่ใส่ -c)
sudo htpasswd /etc/nginx/.htpasswd ai_user2

# ทดสอบเรียก API พร้อม Auth
curl -u ai_user1:password123 https://ai.yourcompany.com/api/generate \
  -d '{"model":"qwen2.5","prompt":"Hello","stream":false}'

ตัวอย่าง: API Key Header (nginx)

# เพิ่มใน nginx server block
# ตรวจสอบ Header "X-API-Key"
location / {
    if ($http_x_api_key != "your-secret-api-key-here") {
        return 401 '{"error": "Unauthorized"}';
    }
    proxy_pass http://ollama;
}

# เรียกใช้:
curl -H "X-API-Key: your-secret-api-key-here" \
  https://ai.yourcompany.com/api/generate \
  -d '{"model":"qwen2.5","prompt":"Hello","stream":false}'

Docker Isolation — รัน Ollama ใน Container

การรัน Ollama ใน Docker Container เป็นอีกชั้นป้องกันที่สำคัญ เพราะแยก Process ออกจาก Host ถ้า Ollama ถูก Exploit ผลกระทบจะจำกัดอยู่ใน Container เท่านั้น:

# docker-compose.yml
version: '3.8'

services:
  ollama:
    image: ollama/ollama:latest
    container_name: ollama-server
    restart: unless-stopped
    ports:
      - "127.0.0.1:11434:11434"  # Bind localhost only!
    volumes:
      - ollama_data:/root/.ollama
    deploy:
      resources:
        limits:
          memory: 16G      # จำกัด RAM สูงสุด
          cpus: '8'         # จำกัด CPU cores
        reservations:
          memory: 4G        # RAM ขั้นต่ำ
    # GPU support (NVIDIA)
    # runtime: nvidia
    # environment:
    #   - NVIDIA_VISIBLE_DEVICES=all

    # Security options
    security_opt:
      - no-new-privileges:true
    read_only: false
    tmpfs:
      - /tmp

volumes:
  ollama_data:
    driver: local

ข้อดีของการรันใน Docker:

• Isolation — แยกจาก Host OS ถ้า Ollama โดน Exploit ไม่กระทบเครื่องหลัก
• Resource Control — กำหนด Memory/CPU สูงสุดได้ ป้องกัน AI กิน RAM จนเครื่องล่ม
• Easy Update — อัปเดตแค่เปลี่ยน Image version แล้ว docker compose up -d
• Reproducible — ย้ายไปเครื่องอื่นง่าย แค่ Copy docker-compose.yml

Firewall & Network — ปิดช่องทางที่ไม่จำเป็น

แม้จะตั้ง Reverse Proxy แล้ว ก็ยังควรตั้ง Firewall เพิ่มอีกชั้น — เป็นหลักการ Defense in Depth ที่ต้องมีหลายชั้นป้องกัน:

# UFW (Ubuntu/Debian)
# ปิด Port 11434 จากภายนอก (Ollama ฟังเฉพาะ localhost)
sudo ufw deny 11434

# เปิด HTTPS สำหรับ nginx Reverse Proxy
sudo ufw allow 443/tcp

# เปิด SSH (สำหรับ Admin)
sudo ufw allow 22/tcp

# เปิด Firewall
sudo ufw enable

# ตรวจสอบ Rules
sudo ufw status verbose

VPN/VLAN สำหรับองค์กรหลายสาขา

ถ้าองค์กรมีหลายสาขาหรือหลาย Site ที่ต้องเข้าถึง AI Server ไม่ควรเปิด Port 443 สู่ Internet โดยตรง แต่ควรใช้:

• VPN (WireGuard / OpenVPN) — เชื่อมเครือข่ายสาขาผ่าน Tunnel เข้ารหัส
• VLAN — แยก AI Server ไว้ใน Subnet เฉพาะ เข้าถึงได้เฉพาะเครื่องที่อนุญาต
• Zero Trust — ทุก Request ต้องยืนยันตัวตน ไม่ว่าจะมาจากในเครือข่ายก็ตาม

Rate Limiting & Monitoring

Rate Limiting ป้องกันไม่ให้ User คนเดียวหรือ Bot ส่ง Request ท่วม Server จน GPU/RAM เต็ม:

nginx Rate Limit Config

# เพิ่มใน http block (/etc/nginx/nginx.conf)
http {
    # จำกัด 2 requests/วินาที ต่อ IP
    limit_req_zone $binary_remote_addr zone=ollama_limit:10m rate=2r/s;

    # จำกัด connections พร้อมกัน 5 ต่อ IP
    limit_conn_zone $binary_remote_addr zone=ollama_conn:10m;

    server {
        # ...
        limit_req zone=ollama_limit burst=5 nodelay;
        limit_conn ollama_conn 5;

        # Custom error message
        limit_req_status 429;
        error_page 429 = @rate_limited;
        location @rate_limited {
            return 429 '{"error": "Too many requests. Please wait."}';
        }
    }
}

Metrics ที่ควร Monitor

Metric	เครื่องมือ	เกณฑ์เตือน	ทำไมต้อง Monitor
Requests/sec	nginx access log / Prometheus	> 50 req/s	ตรวจจับ Abuse / DDoS
Response Time	nginx / Grafana	> 30 วินาที	Model ใหญ่เกิน หรือ Server overload
GPU Usage	nvidia-smi / DCGM Exporter	> 95% นาน > 10 นาที	GPU เต็ม ต้อง Scale หรือ Limit
Memory Usage	Prometheus node_exporter	> 90% RAM	ป้องกัน OOM Kill
Error Rate (4xx/5xx)	nginx error log	> 5% ของ total	ตรวจจับ Bug หรือการโจมตี
Auth Failures	nginx access log (401)	> 10 ครั้ง/นาที จาก IP เดียว	ตรวจจับ Brute Force

Ollama Series — อ่านต่อ

"Self-Host AI ไม่ใช่แค่ติดตั้งแล้วจบ — ต้องดูแลเรื่อง Security เหมือนทุกระบบที่เปิดให้เข้าถึงผ่านเครือข่าย"

- ทีมงาน Saeree ERP

แหล่งอ้างอิง

• Ollama FAQ — Security & Network Configuration (Official)
• nginx Reverse Proxy Documentation
• Docker Security Best Practices (Official)
• OWASP API Security Top 10 (2023)