Keamanan

Amazon Web Services (AWS)

Infrastruktur hosting utama. AWS memiliki sertifikasi SOC 2, ISO 27001, dan sertifikasi kepatuhan lainnya.

Neon (PostgreSQL)

Hosting basis data dengan pencadangan otomatis, enkripsi data tersimpan, dan isolasi jaringan yang aman.

Vercel

Hosting aplikasi dengan HTTPS otomatis, perlindungan DDoS, dan keamanan jaringan edge.

Stripe

Pemrosesan pembayaran bersertifikasi PCI DSS Level 1. Kami tidak pernah menyimpan nomor kartu.

Enkripsi Saat Transit

Semua data yang dikirim antara browser Anda dan server kami dienkripsi menggunakan TLS 1.2 atau lebih tinggi. Kami menerapkan HTTPS untuk semua koneksi dan menggunakan HSTS untuk mencegah serangan downgrade.

Enkripsi Data Tersimpan

Semua data yang tersimpan di database dan penyimpanan file kami dienkripsi dalam keadaan diam menggunakan enkripsi AES-256. Cadangan database juga dienkripsi.

Keamanan Kredensial

Kami tidak menyimpan nama pengguna maupun kata sandi. Seluruh autentikasi ditangani melalui penyedia OAuth (Google dan Microsoft), sehingga kredensial Anda tetap dikelola dengan aman oleh penyedia identitas Anda.

Anthropic (Claude)

• Data tidak disimpan untuk pelatihan melalui API
• Bersertifikasi SOC 2 Type II
• Kontrol keamanan enterprise

Google (Gemini)

• Tidak ada penyimpanan data untuk pelatihan model melalui API
• Keamanan tingkat enterprise
• Bersertifikat ISO 27001, SOC 2

Amazon Bedrock

• Menjalankan model Claude yang sama saat penyedia utama tidak tersedia
• Data tidak disimpan untuk pelatihan sesuai ketentuan layanan AWS
• Bersertifikat ISO 27001, SOC 2

Replicate

• Hanya untuk pembuatan ikon
• Menerima prompt teks yang mendeskripsikan ikon, tidak pernah menerima data Anda

Autentikasi

Kami hanya menggunakan autentikasi OAuth, artinya kami tidak pernah menangani atau menyimpan kata sandi Anda:

• Google OAuth: Masuk dengan aman menggunakan akun Google Anda.
• Microsoft OAuth: Masuk dengan aman menggunakan akun Microsoft Anda.
• Single sign-on: Pada paket Business, masuk melalui penyedia identitas Anda sendiri. Okta dan Microsoft Entra didukung melalui SAML dan OIDC.

Single sign-on dan autentikasi multi-faktor

Flitch tidak menjalankan faktor kedua sendiri dan sama sekali tidak menyimpan kata sandi. Autentikasi didelegasikan, sehingga kontrol yang sudah Anda terapkan adalah kontrol yang berlaku:

• Kebijakan autentikasi multifaktor, aturan akses bersyarat, persyaratan kepatuhan perangkat, dan masa berlaku sesi Anda berlaku di Flitch tanpa perubahan.
• Menghapus seseorang di penyedia identitas Anda akan menghapus cara mereka masuk ke Flitch. Tidak ada kata sandi Flitch terpisah yang perlu dicabut. Kunci API adalah pengecualian dan dijelaskan di bawah.
• Single sign-on hanya aktif setelah Anda membuktikan kepemilikan domain email Anda dengan catatan DNS, sehingga tidak ada yang dapat mengklaim domain yang tidak mereka kendalikan.
• Satu penyedia hanya berlaku untuk satu bisnis dan hanya merutekan domain yang telah diverifikasinya.
• SAML dapat dikonfigurasi sesuai kebutuhan penyedia identitas Anda: permintaan autentikasi bertanda tangan, assertion terenkripsi, dan beberapa sertifikat penandatanganan untuk pergantian sertifikat tanpa downtime. Hubungi kami dan kami akan mengaktifkannya untuk koneksi Anda.

Kunci API dan offboarding

Kunci API dimiliki oleh tim, bukan oleh orang yang membuatnya, sehingga kepergian seorang anggota tidak diam-diam merusak integrasi yang diandalkan tim. Hal ini membawa konsekuensi yang perlu dijelaskan:

• Menghapus seseorang dari penyedia identitas Anda tidak mencabut kunci yang telah mereka buat. Kunci tersebut tetap berfungsi sampai admin tim mencabutnya, yang dapat dilakukan kapan saja melalui Pengaturan, Kunci API.
• Hanya admin tim yang dapat menerbitkan atau mencabut kunci, dan setiap kunci mencantumkan nama pembuatnya, sehingga daftar ini juga berfungsi sebagai daftar periksa saat offboarding.
• Kunci dapat diberi masa kedaluwarsa saat dibuat, yang merupakan cara paling sederhana untuk membuatnya mengoreksi diri sendiri.
• Sebuah kunci hanya dapat mengakses dataset yang diberikan kepadanya, tidak pernah semua dataset di tim, dan tidak pernah apa pun di luar tim tempat kunci itu berada.
• Cakupan log audit adalah pengecualian dari semua hal di atas: cakupan ini diperiksa ulang terhadap pembuatnya pada setiap permintaan, sehingga langsung berhenti berfungsi begitu pembuatnya tidak lagi menjadi admin bisnis.

Keamanan Sesi

• Cookie sesi yang aman dan httpOnly
• Kedaluwarsa sesi otomatis
• Pengelolaan sesi melalui pengaturan akun

Kontrol Akses Tim

Akun tim mendukung kontrol akses berbasis peran dengan peran admin dan anggota. Admin dapat mengelola anggota tim dan mengatur akses ke apa yang dibuat oleh tim.

Pencatatan log audit

Pada paket Business, admin bisnis dapat melihat dan mengekspor semua aktivitas di setiap tim yang mereka miliki:

• Login, perubahan keanggotaan dan peran, berbagi dan publikasi, perubahan sumber data dan kredensial, serta peristiwa penagihan, masing-masing dengan pengguna, waktu, dan hasilnya.
• Ekspor sebagai CSV, JSON Lines, atau OCSF, skema yang dibuat bersama oleh AWS, Splunk, dan CrowdStrike, sehingga langsung masuk ke SIEM Anda tanpa perlu parser yang ditulis untuk kami.
• API polling untuk ingesti berkelanjutan, yang mengirimkan setiap peristiwa tepat satu kali.
• Peristiwa disimpan selama 365 hari.

Saat dukungan Flitch memerlukan akses

Staf kami tidak dapat masuk sendiri ke ruang Anda. Tim dukungan mengajukan permintaan, admin ruang tersebut menyetujui, dan akses berakhir dengan sendirinya. Setiap permintaan, persetujuan, penolakan, dan akses masuk dicatat di log audit Anda sendiri, dan Anda dapat mengakhirinya kapan saja. Dalam keadaan darurat, misalnya tidak ada yang bisa masuk untuk memberikan persetujuan, akses dapat dibuka tanpa menunggu: berlaku selama satu jam, Anda akan dikirimi email saat itu juga, dan kejadiannya dicatat dengan cara yang sama.

Header Keamanan

• Content Security Policy (CSP)
• X-Frame-Options (perlindungan dari clickjacking)
• X-Content-Type-Options
• Strict-Transport-Security (HSTS)
• X-XSS-Protection

Praktik Keamanan

• Validasi dan sanitasi input
• Kueri database berparameter
• Perlindungan token CSRF
• Pembatasan laju pada endpoint sensitif
• Pembaruan dependensi secara berkala

Memanggil alamat

• Alamat privat ditolak. Sebelum langkah webhook atau API memanggil sebuah alamat, host-nya di-resolve dan setiap alamat privat, loopback, link-local, dan metadata cloud ditolak, termasuk nama publik yang mengarah ke salah satunya. Penolakan tidak pernah menampilkan ulang alamat tersebut, karena alamat sering memuat token di path-nya dan riwayat eksekusi Anda dapat dibaca oleh seluruh ruang kerja Anda.
• Diperiksa setiap kali dijalankan, bukan saat disimpan. Nama yang kemarin mengarah ke alamat publik bisa mengarah ke tempat lain hari ini, jadi pemeriksaan dijalankan setiap kali, bukan hanya sekali saat langkah dibuat.
• Pengalihan tidak diikuti. Respons yang mengalihkan ke alamat privat akan melewati pemeriksaan yang baru saja dilakukan, sehingga pengalihan akan mengakhiri panggilan.
• Rahasia webhook bersifat hanya-tulis. Header rahasia yang Anda tetapkan agar sistem tujuan dapat diverifikasi disimpan dan tidak pernah ditampilkan lagi. Header ini juga dihapus dari setiap salinan alur kerja, sehingga menduplikasi alur kerja tidak pernah memberikan kredensialnya kepada siapa pun yang menekan tombol duplikat.

Pengiriman email

• Hanya anggota ruang Anda. Langkah email hanya menjangkau orang di ruang kerja Anda sendiri dan tidak ada orang lain. Jika diminta mengirim email ke setiap pelanggan berisi barisnya masing-masing, langkah ini menolak saat dijalankan dan tidak mengirimkannya.
• Tidak ada yang dikirim dua kali. Langkah yang mengirim data menyimpan watermark, sehingga pengiriman malam hari tidak mengirim ulang baris dari hari sebelumnya. Eksekusi yang sudah mengirim sebagian baris lalu gagal dilaporkan sebagai selesai sebagian, bukan gagal, karena data yang sudah terkirim tidak dapat ditarik kembali dan percobaan ulang akan mengirim baris-baris pertama itu lagi.

Siapa yang dapat memulai eksekusi

• Dashboard tidak dapat mengakses alur kerja kecuali Anda mengizinkannya. Alur kerja hanya dapat diakses dari dashboard atau aplikasi jika memiliki pemicu yang mengizinkannya. Tanpa pemicu tersebut, tidak ada halaman yang dipublikasikan yang dapat menjalankannya. Pemicu ini nonaktif sampai ada yang menambahkannya.
• Halaman yang dipublikasikan membatasi eksekusi dua kali. Pembaca yang sudah masuk adalah seseorang yang identitasnya kami ketahui; pengunjung anonim diminta untuk masuk terlebih dahulu. Mengizinkan siapa saja menjalankannya adalah pengaturan terpisah yang nonaktif sampai Anda mengaktifkannya, dan dalam kedua kasus, jumlah eksekusi dibatasi per pemanggil.
• Eksekusi adalah milik siapa pun yang membuat alur kerja. Eksekusi diotorisasi dan ditagihkan kepada pemilik alur kerja, bukan kepada siapa pun yang menekan tombol. Karena itu, alur kerja yang pemiliknya telah keluar dari ruang kerja tidak dapat diakses oleh siapa pun.

Apa yang dicatat, dan apa yang berhenti

• Setiap eksekusi menyimpan jejak. Langkah demi langkah: apa yang masuk, apa yang keluar, dan contoh baris datanya. Untuk langkah yang berinteraksi dengan dunia luar, dicatat apa yang dikirim, dengan menyebutkan host, bukan alamat lengkapnya. Eksekusi yang dimulai oleh jadwal mencatat tidak ada pelaku, karena tidak ada yang mengawasi; eksekusi yang dimulai oleh seseorang mencatat orang tersebut.
• Alur kerja yang gagal dinonaktifkan. Setelah gagal berturut-turut berulang kali, alur kerja berhenti berjalan sesuai jadwal dan pemiliknya dikirimi email berisi alasannya, sehingga integrasi yang rusak tidak mencoba ulang tanpa batas dan tidak gagal secara diam-diam.
• SQL dijalankan terpisah dari semua kredensial. Kueri yang ditulis dalam alur kerja dijalankan di layanan terpisah, bukan di worker, karena worker menyimpan kredensial database, penyimpanan file, dan model, sedangkan kueri buatan seseorang sebaiknya berjalan jauh dari semuanya. Kueri dijalankan di mesin database yang terkunci: hanya satu SELECT, diverifikasi oleh parser bawaan mesin itu, dengan akses jaringan dan sistem file dinonaktifkan, tanpa ekstensi, dengan batas memori, tanpa menulis apa pun ke disk, dan dengan konfigurasi yang dikunci sehingga kueri tidak dapat mengaktifkan kembali semua itu.