Vai al contenuto

Cosa proteggiamo, come, e cosa manca ancora.

Mettere un gateway davanti al tuo traffico IA è una vera decisione di fiducia, e la prende qualcuno che ha ricevuto un questionario e una scadenza. Questa pagina è scritta per quella persona. Ogni controllo qui sotto indica il meccanismo che lo applica, ogni data è un impegno e non un'aspirazione, e ciò che non abbiamo è elencato con la stessa chiarezza di ciò che abbiamo.

Gli account INFRO sono self-service. Il catalogo, la documentazione e il contratto dell'API sono pubblici, il gateway è in produzione e tutto ciò che va oltre la v1 è indicato come "Più avanti". Piani e prova

Sono impegni sul nostro calendario, non affermazioni sulla conclusione di un auditor. Nulla qui dice che INFRO sia certificata, perché non lo è, e dove una data non è ancora concordata con la società di audit, questa pagina lo dice invece di stimarne una.

Nessuna data è ancora fissata. Una società di audit è incaricata per SOC 2. La finestra di osservazione non è pianificata, quindi qui non c'è nulla da pubblicare, e preferiamo dirlo piuttosto che indicare un trimestre non concordato con la società. Quando sarà pianificata, le date compariranno qui invece di essere inviate ai singoli revisori, così tutti ci tengono allo stesso impegno. Se la tua tempistica dipende da questo, dillo e ti diremo a che punto è davvero la pianificazione: sales@infro.io.

SOC 2 Type I

Auditor incaricato

Il parere di un auditor secondo cui i controlli descritti in questa pagina sono progettati in modo appropriato ed erano in vigore in una data specifica. Non dice nulla sul fatto che abbiano funzionato nel tempo: quello è il Type II.

L'osservazione inizia
Non ancora pubblicato
Report previsto
Non ancora pubblicato

Al completamento questa pagina nomina la società di audit, la data del report e i criteri dei trust services inclusi nell'ambito, e il report stesso viene consegnato sotto NDA. Finché il report non esiste, qui non si rivendica né la società né l'ambito.

SOC 2 Type II

Auditor incaricato

Il parere di un auditor secondo cui quei controlli hanno funzionato efficacemente lungo una finestra di osservazione, che è il report che la maggior parte delle revisioni di sicurezza vuole davvero.

La finestra di osservazione inizia
Non ancora pubblicato
La finestra di osservazione termina
Non ancora pubblicato
Report previsto
Non ancora pubblicato

Una finestra Type II non si può comprimere: il report dura quanto il periodo osservato. Se la finestra si sposta, si sposta con lei la data qui indicata e la modifica viene dichiarata invece di essere corretta in silenzio.

ISO 27001

In valutazione

Certificazione di un sistema di gestione della sicurezza delle informazioni e non di un insieme di controlli. I revisori fuori dagli USA la chiedono più spesso di SOC 2.

In valutazione. Nessun auditor è incaricato e nessuna data è fissata: quindi non c'è una data in questa pagina e non ce ne sarà finché non ci sarà qualcosa a cui impegnarsi. Se ISO è un requisito imprescindibile per te, dillo nella tua prima email; è un segnale utile e può cambiare l'ordine in cui facciamo le cose.

Oggi non deteniamo alcuna certificazione, e nulla qui sopra dice il contrario. Quando esisterà un report, questa pagina indicherà la società di audit, la data del report e i criteri inclusi, e il report viene fornito sotto NDA. Fino ad allora possiamo offrire l'insieme dei controlli qui sotto, il set di risposte e una risposta schietta su dove si trova davvero l'audit; e se il tuo processo richiede un report in mano prima della firma, la risposta giusta è aspettare, non negoziare.

Ciascuno di questi è in atto ora, e ciascuno indica il meccanismo invece dell'intenzione: un trigger del database, un vincolo, un header distribuito. Dove un controllo è una policy e non un meccanismo, lo dice.

Credenziali e chiavi

Le credenziali dei provider sono sigillate e vincolate a un solo tenant
Le chiavi provider che colleghi sono cifrate con AES-256-GCM sotto una chiave conservata come segreto del Worker, mai nel database. Gli identificatori dell'organizzazione e della connessione sono vincolati come dati autenticati aggiuntivi, quindi una credenziale sigillata copiata nella riga di un altro tenant, o in un'altra riga dello stesso tenant, fallisce in modo chiuso invece di decifrarsi. Le credenziali collegate per la riconciliazione dei costi sono sigillate separatamente, con un vincolo proprio.Vincolato come conn:<organization>:<connection> per le credenziali di inferenza e come billing:<organization>:<provider kind> per le credenziali delle API dei costi. Una divulgazione del database da sola non apre nulla.
Non esiste alcuna rivelazione, da nessuna parte
Una volta salvata una credenziale del provider, nessuna interfaccia la restituisce: né la console, né l'API, né la console interna degli operatori. Ciò che ciascuna parte può vedere sono gli ultimi quattro caratteri e i timestamp. Se perdi la chiave, la ruoti presso il provider; non possiamo mostrartela.Le query di connessione della console degli operatori non selezionano affatto la colonna sigillata. Un pulsante di rivelazione è la funzione che trasforma una sessione compromessa nelle chiavi vendor di ogni cliente.
Le chiavi API di INFRO sono sottoposte a hash a riposo
Una chiave del gateway è composta da 32 byte da una fonte casuale crittografica. Ciò che archiviamo è il suo digest SHA-256, un prefisso visualizzato e gli ultimi quattro caratteri, quindi una divulgazione del database non divulga una credenziale utilizzabile. La revoca scrive una tombstone invece di eliminare la riga, così non può essere oscurata da una voce di cache obsoleta ancora in propagazione tra le sedi.SHA-256 invece di una KDF per password è una scelta deliberata: non c'è alcun dizionario da attaccare su 32 byte casuali e una KDF aggiungerebbe 50-200ms di calcolo fatturato a ogni richiesta.
La chiave di cifratura può essere ruotata senza il tuo intervento
Ruotare la chiave che sigilla le credenziali dei clienti risigilla sul posto ogni credenziale archiviata. Non chiede ai clienti di reinserire nulla e l'algoritmo archiviato porta una stringa di versione, così uno schema futuro può coesistere con quello attuale invece di richiedere un giorno di passaggio forzato.Detto chiaramente: perdere quella chiave senza backup è irrecuperabile e ogni cliente dovrebbe ricollegare ogni provider. Backup e ripristino sono scritti come procedura operativa.

I tuoi contenuti

Non addestriamo modelli sui tuoi dati e non li vendiamo
INFRO non usa i tuoi prompt, input o output per addestrare nulla e non li vende. I provider che colleghi trattano i tuoi dati secondo i tuoi accordi e le tue impostazioni dell'account con loro: i controlli di logging di INFRO non cambiano quelle impostazioni e non possono farlo.È l'unico controllo di questa pagina che è una policy e non un meccanismo. È indicato nei termini e nel DPA, che è dove è vincolante.
L'acquisizione di prompt e completamenti è disattivata per impostazione predefinita
I metadati delle richieste (modello, provider, route, conteggi dei token, latenza, costo stimato) sono sempre registrati, perché misurazione, budget e governance sono ciò che il prodotto è. Il contenuto di prompt e completamenti no, a meno che un'organizzazione attivi l'acquisizione. La colonna del database è disattivata per impostazione predefinita; non esiste alcun piano in cui sia attiva per impostazione predefinita.org_settings.prompt_logging_enabled, DEFAULT false NOT NULL fin dalla prima migrazione.
La finestra di conservazione è tua e la pulizia delle eliminazioni è reale
Quando l'acquisizione è attiva, scegli tu la finestra (24 ore, 14, 30, 60 o 90 giorni, oppure un anno) e ciò che viene conservato è il più breve tra la tua scelta e il tetto massimo del tuo piano, quindi una superficie non può mai offrire una finestra che il piano ignorerebbe in silenzio. Un job pianificato elimina i payload acquisiti una volta superata la scadenza, a lotti limitati, così un arretrato non può trasformarsi in una lunga transazione su una tabella su cui scrive il percorso della richiesta.Ogni riga di payload porta il proprio expires_at; la pulizia viene eseguita sul cron al minuto della piattaforma e il suo ritardo è una delle condizioni che fanno scattare un avviso agli operatori. L'eliminazione è un DELETE, non un flag.
L'esportazione delle trace è una allowlist, non una copia
Se invii span OpenTelemetry al tuo collector, l'insieme di attributi è costruito campo per campo e non espandendo una riga del database, così una colonna interna aggiunta in seguito non può finire per impostazione predefinita nel tuo backend di osservabilità. L'endpoint del collector deve essere HTTPS, imposto da un vincolo del database, e gli header che configuri sono sigillati come qualsiasi altra credenziale.È l'unico punto in cui INFRO invia deliberatamente i tuoi dati a un host di terze parti che hai scelto, e l'unico punto in cui una perdita sarebbe duratura. Un test verifica che gli identificatori interni siano assenti dai byte codificati.

Accesso e responsabilità

Il log di audit non può essere riscritto
Ogni modifica di policy, aggiornamento di credenziali, rotazione di chiavi, concessione di piano e modifica dei membri è una nuova riga con un autore e un timestamp. Quelle righe rifiutano UPDATE, DELETE e TRUNCATE a livello di database, non per convenzione e non tramite codice applicativo che uno script di supporto potrebbe aggirare. La storia della tua organizzazione è un registro e non un valore.Imposto da un trigger del database. Né un ingegnere INFRO a un prompt psql né un'applicazione compromessa possono modificarlo di nascosto.
L'identità dei clienti e quella degli operatori non condividono nulla
La console cliente e la console interna degli operatori si autenticano su due sistemi separati: tabelle separate, nomi di cookie separati, segreti di firma separati, allowlist di origini separate. Una sessione cliente presentata a un endpoint operatore è anonima lì e non semplicemente con meno privilegi: porta un nome che quel sistema non cerca, firmato con una chiave che non possiede, rispetto a una tabella che non legge.Il Worker si rifiuta di avviarsi se i due segreti di firma sono uguali o se i due elenchi di origini si sovrappongono. La registrazione degli operatori è disattivata in modo permanente; gli account vengono creati dall'interno e la riga di un operatore sospeso viene conservata proprio perché un controllo di esistenza non possa farlo rientrare.
Autenticazione a due fattori per gli operatori e un passaggio di conferma sulle azioni distruttive
L'autenticazione a due fattori TOTP è disponibile per ogni operatore ed è disattivata per impostazione predefinita: una decisione deliberata, dichiarata qui e non lasciata intendere. Quando è attiva, ogni sessione operatore deve presentare un codice e una password non lo sostituisce mai. Indipendentemente da quell'impostazione, le azioni che cambiano denaro, credenziali o l'accesso di un altro operatore richiedono un secondo fattore presentato negli ultimi 15 minuti; dove l'autenticazione a due fattori è disattivata, quel passaggio di conferma è la password. Dieci errori consecutivi bloccano l'account per quindici minuti.La prova è una riga di fattore per sessione scritta solo dall'hook di verifica, quindi una sessione creata in un altro browser non apre nulla. I codici sono monouso; i codici di backup sono monouso e archiviati cifrati.
Autenticazione a due fattori, passkey e sessioni per i tuoi utenti
Ogni account può attivare l'autenticazione a due fattori con un'app di autenticazione e dieci codici di recupero monouso, e registrare passkey o chiavi di sicurezza hardware, che accedono da sole o fungono da secondo passaggio dopo una password. Un proprietario o amministratore può richiedere l'autenticazione a due fattori per l'intera organizzazione: un membro che non la ha non raggiunge nulla in quell'organizzazione finché non la configura. Il single sign-on soddisfa il requisito, perché il tuo provider di identità applica la propria MFA. Ogni account può vedere dove ha effettuato l'accesso e terminare qualsiasi sessione.I codici sono monouso e dieci errori bloccano l'account per quindici minuti; non esiste il ricordo del dispositivo. Rimuovere un fattore richiede un secondo fattore presentato negli ultimi dieci minuti, non la sola password. Una passkey accede da sola solo se il dispositivo ha verificato l'utente. I codici via email e SMS non sono offerti.
La tua organizzazione non viene mai letta dalla richiesta
Gli endpoint della console e degli operatori prendono l'organizzazione dalla sessione autenticata e la passano come argomento esplicito, così un punto di chiamata non può ometterla e un parametro del corpo o della query che nomina un'organizzazione non può diventare una decisione di autorizzazione presa da input controllato dall'attaccante.Un test strutturale fa passare righe reali attraverso le vere proiezioni di risposta con un valore sentinella, verificando che identificatori interni e corpi di errore upstream non raggiungano mai la risposta a un cliente.

La superficie della piattaforma

Header di sicurezza su tutte e tre le superfici
infro.io, la console cliente e la console degli operatori inviano ciascuna una Content-Security-Policy, HSTS, X-Content-Type-Options: nosniff, X-Frame-Options: DENY, una Referrer-Policy, una Permissions-Policy e una Cross-Origin-Opener-Policy. La console degli operatori aggiunge una resource policy e una direttiva no-index, e la sua pagina di accesso porta una policy con nonce per risposta che non consente alcuno script inline.Verificabile dall'esterno con curl -I su uno qualsiasi dei tre hostname. Uno script versionato percorre ogni route con la policy applicata e fallisce a ogni violazione, così un'origine di terze parti aggiunta non può arrivare in silenzio.
I webhook in uscita sono firmati e ruotano senza lacune
Ogni webhook che inviamo porta una firma HMAC-SHA256 sul timestamp e sul corpo grezzo esatto, così puoi verificare sia l'autenticità sia che il payload non sia stato alterato in transito. Durante una rotazione del segreto una consegna è firmata sia con il vecchio sia con il nuovo segreto, così puoi adottare il nuovo senza perdere consegne.Formato dell'header INFRO-Signature: t=<unix>,v1=<hex>, documentato con codice di verifica. Firma e timestamp sono il motivo per cui un webhook è trattato come una notifica da confermare, mai come un'autorità su cui agire.
Una superficie di errori documentata
Ogni rifiuto del gateway è uno di un insieme pubblicato di tipi e codici, compresi quelli che sono colpa nostra. Le richieste hanno un limite di dimensione prima di qualsiasi parsing, con un 413 documentato invece di un timeout, e le superfici di autenticazione, accesso e lead hanno limiti di frequenza sull'indirizzo di rete del chiamante.Pubblicata per intero su /docs/api/errors prima che tu scriva una riga di codice contro di essa. Gli header dei limiti di frequenza indicano quali sono esatti e quali sono un limite superiore.
Un elenco nominativo dei subprocessori, con preavviso
I vendor che INFRO utilizza sono indicati su /subprocessors, con ciò che ciascuno può effettivamente vedere e dove gira, e 30 giorni di preavviso prima che uno nuovo inizi a trattare dati. I provider AI che servono le tue richieste sono quelli che hai scelto e con cui hai un contratto diretto: non sono subprocessori di INFRO e la pagina spiega perché questa distinzione è reale e non comoda.Oggi due vendor di infrastruttura indicati per nome. Il database gira a Francoforte e il gateway gira accanto ad esso; le richieste entrano nella rete di Cloudflare ovunque si trovi chi chiama, e la pagina lo dice invece di lasciar intendere una regione.

Questo elenco esiste perché il resto della pagina vale meno senza di esso. Se uno di questi blocca un acquisto, è una conversazione che preferiamo avere nella tua prima email e non alla quarta settimana di una valutazione.

Oggi né SOC 2 né ISO 27001
Nessuno dei due è posseduto. Un audit richiede una storia operativa da esaminare e la nostra è breve. La roadmap qui sopra è ciò a cui ci siamo impegnati al suo posto; se il tuo processo non può procedere senza un report in mano, è un motivo per aspettare e non per negoziare.
Nessun penetration test indipendente
Nulla in questa pagina è stato rivisto da qualcuno al di fuori del team che l'ha scritta. Teniamo una revisione di sicurezza interna permanente organizzata per asset ed è un'autovalutazione, che è la differenza tra aver pensato a qualcosa e averlo fatto mettere alla prova da qualcuno.
Nessuna elaborazione solo UE o regionale
Le richieste entrano nella rete di Cloudflare nella sede più vicina a chi chiama, dove termina il TLS, e il gateway stesso gira a Francoforte, accanto al database. Quella collocazione accorcia i round trip verso il database; non è un controllo di residenza dei dati, e l'elaborazione vincolata a una regione richiede diritti di infrastruttura che non abbiamo acquistato. Un hostname dall'aspetto europeo che non vincola davvero l'elaborazione è un'affermazione che potresti smentire con una sola richiesta, quindi non ne serviamo uno.
Il servizio ospitato è multi-tenant
In ogni piano self-service le organizzazioni condividono il servizio ospitato e l'isolamento tra di esse è logico e non fisico. Se il tuo requisito è che il nostro software giri nella tua infrastruttura, si tratta di un deployment self-hosted o ibrido con un accordo enterprise, definito e concordato per contratto; nessun piano self-service ne include uno.
Nessuno SLA di uptime pubblicato nei piani self-service
Un servizio senza una storia operativa non può pubblicare onestamente un impegno di disponibilità, quindi non ne pubblichiamo. Un accordo enterprise può includere uno SLA contrattuale con rimedi, concordato per contratto. Lo stato del gateway è verificabile dal tuo browser su /status.
SSO e SCIM sono nuovi
Il single sign-on SAML e OIDC e il provisioning SCIM 2.0 sono implementati e inclusi dal piano Business, condizionati a un dominio verificato tramite DNS. Non hanno ancora funzionato in produzione con ogni provider di identità, quindi configuriamo la prima connessione con ciascun cliente invece di definirla self-service.
I guardrail sono a pattern; non ci sono guardrail con classificatori
I guardrail per i chat completions, inclusi dal piano Business, controllano prompt e risposte rispetto a pattern fissi (indirizzi email, numeri di telefono, numeri di carta, IBAN, codici previdenziali statunitensi, indirizzi IP, chiavi API e i termini che elenchi) e bloccano, oscurano o segnalano ciò che corrisponde. L'abbinamento a pattern non rileva nulla al di fuori di quei formati. Nulla rileva prompt injection, jailbreak, tossicità o richieste fuori tema, e immagini, audio ed endpoint diversi dai chat completions non vengono ispezionati. Se la tua revisione richiede un classificatore di contenuti sul percorso della richiesta, INFRO non ne fornisce uno.
Nessun tetto di costo per singola richiesta
I budget limitano il totale che la tua organizzazione, un progetto, un membro o una chiave possono raggiungere e i limiti di frequenza limitano il volume di richieste. Ciò che non esiste ancora è un controllo che rifiuti una singola richiesta insolitamente costosa. Un prompt grande legittimo e uno abusivo appaiono uguali al gateway, e un cliente si aspetterebbe ragionevolmente quel controllo.
I limiti di frequenza sono applicati per sede
I limiti sono conteggiati dal servizio di limitazione della frequenza di Cloudflare nella sede in cui viene eseguito il gateway, non da un unico contatore globale. Il gateway è collocato a Francoforte, quindi la maggior parte del traffico è conteggiata lì, ma la collocazione è una preferenza di routing e non una garanzia, e il traffico gestito altrove è conteggiato separatamente: quindi una chiave può superare brevemente il suo limite nominale. È un compromesso deliberato (l'alternativa del contatore globale limita il cliente più grande al nostro livello architetturale e non al suo limite) e la documentazione dell'API indica quali header di limite di frequenza sono esatti e quali sono un limite superiore.

Elenchiamo ciò che non è presente con la stessa chiarezza di ciò che lo è. Se una riga qui blocca un acquisto, preferiamo parlarne ora piuttosto che dopo un contratto.

Nessun addestramento sui tuoi datiImpegnato
INFRO non addestra né vende i tuoi prompt, input o output. L'uso dei dati da parte dei provider AI che colleghi segue i tuoi accordi e le tue impostazioni con loro.
Log dei contenuti disattivato per impostazione predefinitaImpegnato
I metadati di utilizzo servono alla misurazione della piattaforma, alle stime dei costi e alla governance. I log facoltativi di prompt e risposte sono disattivati per impostazione predefinita, archiviati separatamente e limitati dalla conservazione prevista dal tuo piano.
Chiavi con hash a riposoImpegnato
Le chiavi API sono archiviate come digest SHA-256 di 32 byte CSPRNG. Una divulgazione del database non divulga una credenziale utilizzabile e la revoca scrive una tombstone, così non può essere oscurata da una voce di cache obsoleta.
Log di audit in sola aggiuntaImpegnato
Le righe di audit non possono essere aggiornate né eliminate: è il database stesso a rifiutarlo. Ogni modifica di policy, aggiornamento di credenziali, rotazione di chiavi e modifica dei membri è una nuova riga con un autore, così la storia della tua organizzazione non può essere riscritta di nascosto.
Elenco dei subresponsabili pubblicatoImpegnato
I vendor di infrastruttura sono indicati su /subprocessors, con 30 giorni di preavviso prima che uno nuovo inizi a trattare dati, fatta salva l'eccezione d'emergenza ivi descritta. Scegli e stipuli direttamente il contratto con i provider AI che colleghi.
SOC 2 / ISO 27001Non ancora
Non posseduta e non rivendicata. Una certificazione richiede una storia operativa da sottoporre ad audit e quella del gateway è breve. Ciò che viene pubblicato invece è la roadmap su /trust: una società di audit è incaricata per SOC 2 senza ancora una finestra di osservazione pianificata, ISO 27001 è in valutazione senza auditor e senza data, e nessuna delle due è descritta come qualcosa di più. Le date compaiono lì quando la società le concorda, non prima.
DPA con Standard Contractual ClausesImpegnato
Pubblicato integralmente su /dpa, con le SCC e l'Addendum UK. La firma avviene via email e non dalla console: non esiste un flusso di controfirma, e la pagina lo dice invece di lasciar intendere un pulsante.
Residenza dei dati nell'UENon ancora
Richiede diritti infrastrutturali che non abbiamo acquistato. Un hostname che sembra soltanto europeo è un'affermazione che un cliente può smentire con una sola richiesta, quindi non ne offriremo uno finché l'elaborazione non sarà realmente vincolata.

Le nostre risposte alle domande che una revisione di sicurezza pone davvero (gestione dei dati, cifratura, gestione delle chiavi, controllo degli accessi, monitoraggio, conformità), pubblicate come documento di testo semplice che puoi leggere, confrontare e incollare nei tuoi strumenti.

Scarica il set di risposteLeggilo nel browser

È in Markdown e non un foglio di calcolo CAIQ, di proposito. Il valore del CAIQ è la sua numerazione delle domande, e uno compilato in parte fa pensare all'iscrizione a un registro di cui non facciamo parte: quindi questo copre gli stessi temi nell'ordine in cui li legge un revisore, in un formato che sia i tuoi strumenti sia i nostri possono confrontare. È generato dagli stessi dati di questa pagina, quindi i due non possono divergere.

Invia anche il tuo questionario, in qualunque forma sia. Rispondiamo a ogni domanda, comprese quelle in cui la risposta è no, e diciamo quali di queste hanno una data. Scrivi a sales@infro.io.

Leggili prima di chiederci qualcosa. Nessuno di questi richiede una chiamata, un NDA o una conversazione commerciale per essere consultato.

Accordo sul trattamento dei dati
Il testo completo, che incorpora le Clausole Contrattuali Standard con l'Addendum UK, compresi l'obbligo di notifica delle violazioni e il calendario di retention. La sottoscrizione avviene via email: non c'è un flusso di controfirma nella console, e la pagina lo dice invece di far pensare a un pulsante.
Subresponsabili
Ogni fornitore che INFRO incarica, cosa può effettivamente vedere ciascuno, dove opera, e 30 giorni di preavviso prima che uno nuovo inizi il trattamento. Spiega anche perché i provider IA che colleghi non sono sub-responsabili del trattamento di INFRO.
Informativa sulla privacy
Cosa viene raccolto, le basi giuridiche, per quanto tempo viene conservata ogni categoria e i diritti a disposizione dell'interessato. Coerente con le finestre di retention di questa pagina, non in contraddizione.
Policy di utilizzo accettabile
Cosa non si può costruire sulla piattaforma, comprese le categorie senza possibilità di approvazione, e cosa succede quando lo scopriamo. Scritto nel lessico dei circuiti di pagamento, perché sono loro a chiederlo.
Policy di divulgazione delle vulnerabilità
Cosa rientra nell'ambito, come testare senza danneggiare un altro cliente, a cosa ci impegniamo quando segnali e il safe harbour per la ricerca in buona fede. Pubblicato anche come /.well-known/security.txt.
Termini di servizio
Il contratto commerciale, l'entità che gestisce il servizio e la sua giurisdizione, e cosa succede a un account alla sua fine.
La tassonomia degli errori
Ogni rifiuto che il gateway può dare, pubblicato prima che tu scriva una riga di codice: compresi quelli che sono colpa nostra e non tua.
Gestione dei dati, nel riferimento API
Campo per campo: cosa viene registrato su ogni richiesta, cosa aggiunge l'acquisizione quando un'organizzazione la attiva e come si applica la finestra di retention. La versione per ingegneri del controllo di retention descritto sopra.
Chiavi e autenticazione
Come vengono emesse le chiavi del gateway, limitate a un progetto e a un ambiente, ristrette per ruolo e revocate: scritto per chi deve decidere chi nella tua organizzazione ne riceve una.
Sicurezza delle chiavi API IA
Dove vivono le chiavi dei provider con e senza un gateway, i quattro controlli che ogni chiave del gateway supera prima di chiamare un provider e cosa fare nella prima ora dopo l'esposizione di una chiave.

Hai trovato qualcosa?

Inviala a security@infro.io. Quella casella è letta dalle persone che possono risolvere il problema, ed è per le segnalazioni di vulnerabilità, non per il supporto.

Ambito, regole di test e safe harbour per intero: la policy di divulgazione delle vulnerabilità.

  • Confermiamo la ricezione entro un giorno lavorativo e ti teniamo aggiornato durante l'indagine, anche quando la risposta è che lo sapevamo già.
  • La ricerca in buona fede è al sicuro qui. Non intraprenderemo azioni legali per test che evitano violazioni della privacy, degrado del servizio e distruzione o esfiltrazione di dati che non sono tuoi.
  • Non esiste un programma di bug bounty né alcun compenso. Lo diciamo subito, perché scoprirlo dopo il lavoro è peggio che saperlo prima.
  • Le domande commerciali e di procurement vanno altrove: sales@infro.io per una revisione di sicurezza o un questionario, support@infro.io per un account che hai già.