Seguridad sa Lendbox

• Tumatakbo ang Lendbox sa Amazon Web Services sa rehiyong us-east-1, Estados Unidos. Ang aplikasyon, ang database, at ang mga na-upload na dokumento sa Amazon S3 ay pawang nasa rehiyong iyon.
• Naka-encrypt ang data habang isinasalin gamit ang TLS 1.3.
• Naka-encrypt ang nakaimbak na data gamit ang AES-256. Ang mga storage volume ng database at aplikasyon ay naka-encrypt gamit ang AWS EBS encryption. Ang mga na-upload na dokumento at backup ay naka-encrypt sa panig ng server sa Amazon S3. Ang mga encryption key ay pinamamahalaan sa pamamagitan ng AWS Key Management Service.
• Maaaring i-export ng mga kliyente ang kabuuan ng kanilang data anumang oras mula sa loob ng produkto. Hindi kailangang humiling sa amin.

Kapag isinara ang account, itinatago ang data ng kliyente nang 60 araw at pagkatapos ay permanenteng binubura. Sa loob ng panahong iyon, maaaring ibalik ang account kapag hiniling.

• Tumatakbo ang aplikasyon at database sa hiwalay na AWS infrastructure. Hindi maaabot ng publiko ang mga database at hindi ito tumatanggap ng koneksyon mula sa internet. Ang web layer ay inihahatid ng Vercel.
• Dumadaan sa Cloudflare ang lahat ng papasok na trapiko, na nagbibigay ng DDoS mitigation at web application firewall.
• Hiwalay ang mga environment: magkahiwalay na imprastraktura ang production, staging, at development, at walang pinagsasaluhang credential. Walang production data ang development at staging.

Ang mga kontrol sa seksyong ito ay pinapatakbo ng kliyente, hindi namin. Ang institusyon mismo ang nagse-set nito, at maaari nitong tingnan anumang oras kung ano ang magagawa ng bawat kawani.

• Antas-antas na permission bawat module. Maaaring itakda ang bawat module para sa bawat kawani sa isa sa anim na antas na nasa ibaba.
• Pagtatalaga ng role sa maraming sangay. Maaaring bigyan ang isang account ng access sa ilang sangay at magkaroon ng magkaibang role sa bawat isa, kaya ang branch manager sa isang lugar ay view-only na user sa iba.
• Paghihiwalay ng humihiling at nag-aapruba. Ang mga sensitibong aksyon ay hinahati sa pagitan ng kawaning humihiling at ng kawaning nag-aapruba. Nako-configure ang approval workflow bawat institusyon, kasama ang bilang ng hakbang at kung aling role ang maaaring kumilos sa bawat hakbang.
• Multi-factor authentication. Available sa bawat pag-login, at maaaring i-enable nang hiwalay ng bawat user at kawani.
• Nag-e-expire ang mga session pagkatapos ng 5 araw at kailangang mag-authenticate muli.

• Bawat aksyon sa loob ng produkto ay naitatala kasama ang user na gumawa nito, ang apektadong record, at ang timestamp.
• Append-only ang mga audit record. Hindi ito maaaring i-edit o burahin mula sa aplikasyon, kahit ng mga administrator ng institusyon.
• Ang mga saradong accounting period ay naka-lock laban sa retroactive na pagbabago.
• Maaaring i-export ng mga administrator ng institusyon ang audit history anumang oras.

Itinatago ang audit history sa buong buhay ng account, mula sa petsang nilikha ito. Walang rolling window at walang pagputol.

• Bina-back up ang mga database kada oras.
• Naka-encrypt ang mga backup at itinatago nang 6 buwan.
• Recovery point objective (RPO): 1 oras.

Sinusubukan ang pag-restore kada linggo sa isang non-production environment. Ang backup na hindi pa nasusubukang i-restore ay hindi backup.

• Ang access sa production data ay limitado sa iisang pinangalanang tao, ang founder. Walang ibang empleyado, kontratista, o third party ang may hawak ng production credential. Sinadyang desisyon ito sa disenyo: ito ang pinakamaliit na posibleng bilang ng taong makakaabot sa data ng kliyente.
• Indibidwal ang credential sa production access at protektado ito ng multi-factor authentication. Walang ginagamit na shared account o credential kahit saan sa organisasyon.
• Ang mga secret at credential ng aplikasyon ay pinamamahalaan sa Doppler. Hindi ito itinatago sa source control o sa makina ng mga developer.
• Pagpapatuloy: may nakadokumentong break-glass na proseso para sa sitwasyong hindi available ang taong may hawak ng production credential. Ang recovery credential ay nakalagak nang selyado sa isang pinangalanang pangalawang partido, inilalabas sa tinukoy na kondisyon, at naitatala ang bawat paggamit. Ibinabalik ng proseso ang access ng kliyente sa sarili nilang data; hindi ito nagbibigay ng permanenteng access kaninuman.

Inaayos ang mga security vulnerability ayon sa target na batay sa severity, na binibilang mula sa sandaling nakumpirmang apektado ang Lendbox.

• Tuloy-tuloy na sinusubaybayan ang mga dependency ng aplikasyon gamit ang Renovate, na awtomatikong nagbubukas ng patch pull request habang inilalabas ang mga upstream na bersyon.
• Sinusuri at pinagsasama ang mga dependency update sa lingguhang siklo. Ang mga advisory na may kilalang exploit ay lumalaktaw sa siklong ito at agad na inaaksyunan.
• Ang mga base image ng operating system at container ay muling binubuo at ide-deploy buwan-buwan, at agad kapag may inihayag na kritikal na vulnerability.

Ang mga serbisyong nakalista rito ay nagpoproseso ng data para sa amin sa ilalim ng kontrata.

Inaabisuhan ang mga kliyente sa pamamagitan ng email nang hindi bababa sa 30 araw bago magdagdag ng bagong subprocessor o palitan ang isang umiiral, sa administratibong kontak ng account.

Mga self-hosted na bahagi

Ang mga sumusunod ay tumatakbo sa imprastrakturang kontrolado namin. Pinapangalanan ang mga ito dahil nakikita ng sinumang sumusuri sa produkto, ngunit hindi sila subprocessor: walang third party na tumatanggap ng data sa pamamagitan nila.

• Tuloy-tuloy na sinusubaybayan ang kalusugan ng imprastraktura at aplikasyon gamit ang Prometheus, Alertmanager, at cAdvisor, at ang mga alerto ay iniruruta sa on-call na inhinyero.
• Kapag may security incident na umaapekto sa data ng kliyente, inaabisuhan ang mga apektadong kliyente sa loob ng 72 oras mula sa kumpirmasyon. Nakasaad sa abiso kung ano ang nangyari, aling data ang naapektuhan, ano ang ginawa namin para pigilan ito, at anong hakbang, kung mayroon man, ang kailangang gawin ng kliyente.
• Ini-post ang mga availability incident sa status page habang inaayos pa lamang, hindi pagkatapos malutas.

• Mag-email sa [email protected]. Isama ang mga hakbang para maulit ito.
• Kinikilala namin ang bawat ulat sa loob ng 3 araw ng negosyo, at nagbibigay ng pagtatasa ng severity at inaasahang timeline ng pag-aayos sa loob ng 10 araw ng negosyo.
• Hindi kami naghahain ng aksyong legal laban sa mga mananaliksik na nag-uulat nang may mabuting hangarin, umiiwas sa paglabag sa privacy at pagpapabagal ng serbisyo, at nagbibigay sa amin ng makatwirang panahon para makapag-ayos bago ihayag.
• Ang aming machine-readable na detalye ng kontak ay inilalathala sa /.well-known/security.txt.