Beklemede şifreleme
Platform veritabanında saklanan hassas alanlar, diske yazılmadan önce AES-256-GCM ile şifrelenir.
| Ne | Nasıl |
|---|---|
| Tenant API anahtarları (Anthropic, OpenAI uyumlu, SMTP) | AES-256-GCM, MASTER_ENCRYPTION_KEY |
| Kullanıcı şifresi hash'leri | bcrypt (cost 12) |
| BYOD bağlantı dizeleri | AES-256-GCM, MASTER_ENCRYPTION_KEY |
| IMAP / e-posta kanal kimlik bilgileri | AES-256-GCM, MASTER_ENCRYPTION_KEY |
| Diskteki veritabanı dosyaları | Şifreli birimde MySQL InnoDB tablespace TODO: confirm full-disk encryption status with ops |
MASTER_ENCRYPTION_KEY, başlangıç sırasında sunucu ortamı aracılığıyla enjekte edilir ve kod tabanına veya veritabanına asla yazılmaz. Rotasyon, yeniden şifreleme çalışması gerektirir ve ops runbook'unda belgelenmiştir. TODO: link ops runbook once published
Aktarım sırasında şifreleme
- Tüm genel uç noktaları yalnızca HTTPS üzerinden sunulur; HTTP, HTTPS'ye yönlendirilir (Apache HSTS başlığı).
- Minimum TLS sürümü: TLS 1.3 (TLS 1.0 / 1.1 devre dışı).
- Widget widget.js, Access-Control-Allow-Origin: * ile sunulur, ancak chat API uç noktaları widget_key + origin allowlist'i doğrular.
- İç hizmet çağrıları (Redis, localhost'taki MySQL) loopback arayüzü üzerinden iletişim kurar. Hiçbir veri, host'tan şifrelenmemiş olarak çıkmaz.
Yedeklemeler
Aşağıdaki yedekleme programı platform veritabanı ve tenant veritabanları için geçerlidir:
| Öğe | Sıklık | Saklama | Konum |
|---|---|---|---|
| Platform VT (einstein_saas_platform) | Her gün, gece (UTC, otomatik) | 7 günlük yedek (dönüşümlü) | Yerel birim + şifreli dış konum kopyası |
| Tenant VT'leri (einstein_saas_tenant_*) | Her gün, gece (UTC, otomatik) | 7 günlük yedek (dönüşümlü) | Yerel birim + şifreli dış konum kopyası |
| Yüklenen dosyalar / belge depolama | Her gün, gece (UTC, otomatik) | 7 günlük yedek (dönüşümlü) | Yerel birim + şifreli dış konum kopyası |
Yedekler her veritabanı için mysqldump --single-transaction ile çalışır, sıkıştırılmış ve age ile şifrelenmiş olarak saklanır, ayrı bir dış konum birimine kopyalanır ve her çalıştırma boş olmayan bir döküm için kontrol edilir ve başarı/başarısızlık durumuyla günlüğe kaydedilir.
Yedek arşivleri beklemede age (X25519 / ChaCha20-Poly1305) ile şifrelenir; şifre çözme anahtarı arşivlerden ayrı tutulur. Sütun düzeyinde şifrelemeyle (AES-256-GCM) korunan alanlar her arşivde şifreli kalır. Kurtarılabilirlik, otomatik aylık geri yükleme testiyle doğrulanır.
Erişim kontrolü
4.1 Rol tabanlı erişim kontrolü (RBAC)
Her portal kullanıcısına bir rol atanır. Roller ayrıntılı izinler içerir (51+ bireysel bayrak). Platform, izin kontrollerini her API uç noktasında sunucu tarafında uygular.
4.2 İki faktörlü kimlik doğrulama
- TOTP (RFC 6238 — Google Authenticator, Authy vb.) üzerinden 2FA, sahip rolü için zorunludur ve girişte uygulanır.
- Hesap sahipleri, ayarlar paneli üzerinden tüm ekip üyeleri için 2FA'yı zorunlu kılabilir.
- Yedek kurtarma kodları kayıt sırasında oluşturulur ve kullanıcı tarafından güvenli şekilde saklanmalıdır.
4.3 Tenant izolasyonu
Kimlik doğrulama, tenant bağlamı gerektirir (slug tabanlı giriş). Oturum token'ları tek bir tenant ile sınırlıdır. Tenant'lar arası kaynak erişimi, tüm sorgularda zorunlu tenant_id filtreleri aracılığıyla uygulama katmanında önlenir.
Denetim günlüğü
Platform kaynaklarındaki önemli eylemler audit_log tablosuna (platform veritabanı) kaydedilir. Her giriş şunları içerir:
- Aktör: kullanıcı kimliği, rol ve tenant kimliği.
- Eylem: fiil (oluştur, güncelle, sil, giriş yap, dışa aktar, …).
- Kaynak: varlık türü ve kimliği.
- Meta veri: değiştirilen alan adları ve eski/yeni değerler (hassas alanlar düzenlendi).
- Zaman damgası: UTC'de saklanır (ISO 8601).
- IP adresi: isteğin kaynak IP'si.
Denetim günlüğü girişleri 2 yıl saklanır. Günlük, uygulama düzeyinde salt eklemedir.
Denetim yazma işlemleri için özel bir salt ekleme veritabanı kullanıcısı (einstein_audit_writer) kullanılır; bu, uygulama veritabanı kullanıcısı tarafından günlük girişlerinin değiştirilmesini veya silinmesini önler.
Güvenlik açığı yönetimi
6.1 CVE izleme
Composer bağımlılıkları, her dağıtım işlem hattı çalıştırmasında composer audit aracılığıyla izlenir. Çalışma zamanı bağımlılıklarındaki kritik CVE'ler, yayından sonra 72 saat içinde bir bant dışı yamanın tetiklenmesine neden olur. TODO: confirm SLA with ops
6.2 Yama döngüsü
- İşletim sistemi güvenlik yamaları: haftalık bakım penceresi sırasında uygulanır. TODO: confirm window day/time with ops
- PHP çalışma zamanı: etkin dalın en son kararlı küçük sürümünde tutulur (şu anda PHP 8.2.x).
- Web sunucusu: Apache 2.4.x — dağıtım güvenlik güncellemeleriyle güncel tutulur.
6.3 Sorumlu ifşa
Dış güvenlik araştırmacıları, koordineli ifşa politikamız kapsamında güvenlik açıklarını bildirmeye davet edilir. Sorumlu ifşa politikasını okuyun →
Hosting ve altyapı
| Bileşen | Ayrıntı |
|---|---|
| Barındırma bölgesi | AB — Hollanda |
| Üretim sunucusu | dev01-aionized (Ubuntu) |
| Web sunucusu | Apache 2.4 (mod_rewrite, mod_ssl) |
| Runtime | PHP 8.2+ |
| Veritabanı | MySQL / MariaDB (platform + per-tenant) |
| Önbellek / oturumlar | Redis (loopback, password-protected) |
| Sınır ötesi veri transferleri | Varsayılan olarak hiçbiri. İsteğe bağlı bulut-AI çağrıları (Anthropic/OpenAI-uyumlu) kullanıcı rızası kapılandırılır ve Standart Sözleşme Şartları tarafından kapsanır. |