Forums One juridiskā informācija
Drošības un atbilstības kontrole
Forums One launch drošības vārti, apakšapstrādātāju reģistrs, incidentu process, atbalsta piekļuve un klienta pienākumi.
- Versija
- 2026-07-06-launch
- Juridiskā persona
- Sabiedrība ar ierobežotu atbildību "Forum Design"
- Reģistrācijas Nr.
- 40203656019
- Kontakti
- info@forums1.io
1. Launch vārti
| Joma | Prasība | Statuss |
|---|---|---|
| Juridiskie dokumenti | Noteikumi, privātums, DPA un sīkdatnes publicētas ar SIA “Forum Design” datiem. | Apstiprināts |
| Juridiskā persona | Pārdevējs/pārzinis: SIA “Forum Design”, reģ. Nr. 40203656019, nav PVN maksātājs. | Apstiprināts |
| Stripe un nodokļi | 50 EUR mēneša abonements agrīnajiem lietotājiem; PVN netiek iekasēts, jo pārdevējs nav PVN maksātājs. | Jāapstiprina ar Stripe live cenu |
| Sīkdatnes | Papildu sīkdatnes drīkst aktivizēt tikai pēc piekrišanas; atteikums un atsaukšana jāstrādā. | Ieviests |
| Apakšapstrādātāji | DPA/SCC, reģions, datu kategorijas un piekļuves apjoms uzturēts reģistrā. | Apstiprināts |
| Incidentu process | 72h DVI pulkstenis, klienta paziņošana un iekšējais incidentu reģistrs. | Apstiprināts |
| Supabase drošība | Leaked-password protection, RLS, storage privacy un service-role route testi jāverificē pirms pārdošanas slēdža. | Jāverificē produkcijā |
| Demo režīms | Reālā produkcijas vide nedrīkst darboties ar NEXT_PUBLIC_DEMO_MODE=1. | Jāverificē Vercel Production |
2. Galvenās drošības kontroles
| Kontrole | Apraksts |
|---|---|
| Autentifikācija | Supabase Auth, sesijas pārbaudes, MFA stāvoklis, demo login tikai demo režīmā. |
| Autorizācija | Dalība uzņēmumā, lomas, RLS un servera puses pārbaudes pirms datu darbībām. |
| Dokumenti | Privāti storage bucket, uzņēmuma prefiksi, MIME/izmēra validācija, parakstītas īslaicīgas saites. |
| Servisa loma | SUPABASE_SERVICE_ROLE_KEY tikai servera API maršrutos; nekad klienta bundle. |
| Atbalsts | Piekļuve klienta datiem tikai pamatotam pieprasījumam vai incidentam; jāreģistrē katra piekļuve. |
| AI/OCR | Datu minimizācija, bez klienta datu izmantošanas modeļu apmācībai, cilvēka pārbaude pirms lēmumiem. |
| Žurnāli | Drošības, atbalsta, billing un incidentu pieraksti ar retenci atbilstoši riskam un likumam. |
| Izmaiņas | Migrations only datubāzei; nav manuālu production DB labojumu; RLS/storage acceptance pēc izmaiņām. |
3. Datu rezidence un izolācija
Produkcijas mērķis ir ES datu rezidence un uzņēmumu datu izolācija. Katram klientam un uzņēmumam jābūt loģiski nodalītam ar datubāzes RLS, servera puses lomu pārbaudēm un failu glabāšanas ceļiem, kas nepieļauj nejaušu piekļuvi cita uzņēmuma dokumentiem.
- Anonīmi lietotāji nedrīkst lasīt tenant tabulas.
- Viewer lomas nedrīkst mainīt lomas vai dalību.
- Lietotājs nedrīkst piekļūt cita uzņēmuma datiem ārpus savas dalības.
- Darbinieku scoped dokumentiem jābūt redzamiem tikai atbilstošajam darbiniekam vai pilnvarotām lomām.
4. Apakšapstrādātāju reģistrs
| Provideris | Loma | Reģions | Datu kategorijas | Apstiprinājums |
|---|---|---|---|---|
| Supabase | Autentifikācija, datubāze, failu glabātava un žurnāli | ES, Frankfurte | Konti, uzņēmumu dati, dokumentu metadati, lietotāju tiesības, tehniskie žurnāli | Apstiprināts. Apstiprināts publiskai palaišanai; jāuztur ES datu rezidence un drošības iestatījumi |
| Vercel | Lietotnes izvietošana, tīkla aizsardzība un izvēršanas žurnāli | ES/EEZ un apstiprināti apakšapstrādātāji | Tehniskie pieprasījumi, sesiju metadati, lietotnes žurnāli | Apstiprināts. Apstiprināts publiskai palaišanai |
| Stripe | Maksājumi, rēķinu izrakstīšana un klienta norēķinu portāls | ES/EEZ un apstiprināti apakšapstrādātāji | Norēķinu kontakti, maksājumu statuss, rēķinu metadati | Apstiprināts. Apstiprināts publiskai palaišanai; PVN iekasēšana nav ieslēgta, jo pārdevējs nav PVN maksātājs |
| AI pakalpojumu sniedzējs | Dokumentu nolasīšana, klasifikācija un palīgfunkcijas | ES/EEZ vai līgumiski apstiprināta pārsūtīšana | Dokumentu saturs tikai apstrādes uzdevuma izpildei, bez modeļu apmācības | Apstiprināts. Apstiprināts publiskai palaišanai; klientu dati netiek izmantoti modeļu apmācībai |
| E-pasta pakalpojumu sniedzējs | Darījumu e-pasti, uzaicinājumi un atbalsta paziņojumi | ES/EEZ vai apstiprināta pārsūtīšana | E-pasta adreses, ziņojumu metadati, piegādes statuss | Apstiprināts. Apstiprināts publiskai palaišanai |
| Observability un kļūdu uzraudzība | Kļūdu žurnāli, veiktspējas mērījumi un incidentu diagnostika | ES/EEZ vai apstiprināta pārsūtīšana | Tehniskie žurnāli, kļūdu konteksts, ierobežoti lietotāja metadati | Apstiprināts. Apstiprināts publiskai palaišanai; jāuztur datu maskēšana un retence |
5. Incidentu process
Incidentu process ir paredzēts, lai ātri noteiktu faktus, izolētu risku, dokumentētu pierādījumus un izvērtētu, vai jāinformē klients, datu subjekti vai Datu valsts inspekcija. Personas datu incidentiem jāuztur 72 stundu DVI izvērtēšanas pulkstenis no brīža, kad pārkāpums kļuvis zināms.
- Reģistrēt incidenta sākuma laiku un pirmo pamanīšanas brīdi.
- Noteikt, vai incidents skar personas datus, uzņēmumu dokumentus vai piekļuves tiesības.
- Sākt 72 stundu DVI izvērtēšanas pulksteni no brīža, kad pārkāpums kļuvis zināms.
- Izolēt skarto sistēmu vai kontu un saglabāt pierādījumus.
- Novērtēt risku datu subjektiem un klienta uzņēmumam.
- Paziņot klientam bez nepamatotas kavēšanās, ja Forums One darbojas kā apstrādātājs.
- Sagatavot DVI paziņojumu, ja risks sasniedz paziņošanas slieksni.
- Dokumentēt korektīvās darbības, atbildīgo personu un slēgšanas laiku.
6. Atbalsta piekļuves žurnāls
Atbalsta piekļuve klienta datiem ir izņēmuma, nevis noklusējuma process. Piekļuves iemeslam jābūt konkrētam: klienta pieprasījums, kļūdas diagnostika, drošības incidents vai juridiski pamatots process.
- Datums un laiks
- Atbalsta darbinieks
- Klienta uzņēmums
- Piekļuves iemesls
- Skartie dati vai modulis
- Klienta pieprasījuma vai incidenta atsauce
- Veiktās darbības
- Piekļuves slēgšanas laiks
7. Klienta drošības pienākumi
- Piešķirt lietotājiem minimāli nepieciešamās tiesības un regulāri tās pārskatīt.
- Deaktivizēt lietotājus un ārējos konsultantus, kuriem piekļuve vairs nav nepieciešama.
- Pārbaudīt dokumentu, bankas un algu datu pareizību pirms to izmantošanas.
- Neaugšupielādēt failus vai personas datus, kurus klientam nav tiesību apstrādāt.
- Ziņot par aizdomīgu piekļuvi, nepareizām tiesībām, datu noplūdi vai maksājumu/dokumentu neatbilstībām.
8. Service-role un klienta bundle kontrole
Servisa lomas atslēgas drīkst izmantot tikai servera pusē, un katram maršrutam, kas izmanto paaugstinātas tiesības, jāveic sesijas, lietotāja, lomas un uzņēmuma dalības pārbaude. Klienta bundle nedrīkst saturēt server-only noslēpumus, service-role atslēgas vai privātas API atslēgas.
9. Reālas produkcijas pieņemšanas pārbaude
- Noņemt `NEXT_PUBLIC_DEMO_MODE=1` un pārbaudīt, ka demo fallback vairs nestrādā.
- Apstiprināt Supabase Auth leaked-password protection.
- Palaist RLS testus anon, viewer, cross-company un employee-scoped dokumentu scenārijiem.
- Pārbaudīt private storage, signed URLs, MIME/size limitus un company-prefixed paths.
- Pārbaudīt, ka checkout metadatos nonāk aktuālās legal/cookie versijas un consent statuss.
- Pārbaudīt Vercel/Supabase logs pēc deploy bez runtime erroriem.