# Sicurezza del dispositivo (/it/in-store/security/device_security) Tapaya Accept SDK trasforma dispositivi di largo consumo disponibili in commercio (COTS, consumer off-the-shelf) in terminali di pagamento sicuri. Poiché questi dispositivi non sono hardware di pagamento dedicato, l'SDK applica misure di sicurezza rigorose per mitigare le minacce e garantire la conformità agli standard PCI. ## Attestazione del dispositivo [#device-attestation] Per garantire che l'ambiente di pagamento sia sicuro, l'SDK esegue controlli continui sullo stato del dispositivo host. Se rileva una qualsiasi violazione della sicurezza, l'SDK si rifiuta di inizializzarsi o di elaborare transazioni. ### Rilevamento di root e jailbreak [#root-and-jailbreak-detection] L'SDK monitora l'ambiente alla ricerca di indicatori di escalation dei privilegi. Ciò include il rilevamento di binari di root o di framework di gestione dei privilegi come Magisk o SuperSU. Verifica inoltre eventuali accessi non autorizzati in lettura o scrittura a directory di sistema protette. Identifica anche build non standard del sistema operativo, comprese ROM personalizzate o firme del kernel modificate. ### Rilevamento del debug [#debugging-detection] Per impedire il reverse engineering e i test non autorizzati, l'SDK rileva se all'applicazione è collegato un debugger e verifica di essere in esecuzione su un dispositivo fisico. L'esecuzione è limitata in emulatori o ambienti virtuali. ### Google Play Integrity API [#google-play-integrity-api] Su Android, l'SDK utilizza la **Play Integrity API** per verificare che il binario del dispositivo sia riconosciuto da Google e non sia stato manomesso. ## Sicurezza dell'applicazione [#application-security] ### Offuscamento del codice [#code-obfuscation] Tapaya Accept SDK utilizza tecniche di offuscamento avanzate per ridurre il rischio di reverse engineering. I simboli del codice vengono rinominati con identificatori non descrittivi, la logica del programma viene deliberatamente resa oscura e le stringhe sensibili o le chiavi incorporate vengono cifrate. ### Protezione dalle manomissioni [#anti-tampering] L'SDK verifica la propria integrità in fase di esecuzione. Controlla la firma digitale dell'applicazione e delle librerie dell'SDK. Se l'APK è stato modificato o ricompilato da terzi, l'SDK non si avvia. ## Protezione dei dati [#data-protection] ### Crittografia end-to-end (E2EE) [#end-to-end-encryption-e2ee] I dati della carta vengono cifrati non appena vengono letti dal controller NFC. Si utilizza una crittografia robusta conforme agli standard di settore, e le chiavi di decifratura sono conservate esclusivamente all'interno di HSM sicuri. Il dispositivo mobile non ha mai accesso ai dati della carta in chiaro. ### Inserimento sicuro [#secure-input] Per le transazioni con PIN, l'SDK garantisce un inserimento sicuro. La schermata del PIN è protetta dagli attacchi tramite overlay, la disposizione del tastierino è casuale e per ogni input tattile viene verificato che provenga dal dispositivo fisico. ## Monitoraggio dell'ambiente [#environment-monitoring] ### Blocco della registrazione dello schermo [#screen-recording-prevention] Per proteggere i dati sensibili, l'SDK blocca screenshot, registrazioni dello schermo e condivisione dello schermo imponendo controlli di visualizzazione sicura sul dispositivo. ### Servizi di accessibilità [#accessibility-services] Le app dannose abusano spesso dei servizi di accessibilità per leggere il contenuto dello schermo o iniettare input. L'SDK rileva i servizi di accessibilità attivi. Pur consentendo i servizi standard per gli utenti con disabilità visive (come TalkBack), può bloccare servizi sconosciuti o sospetti durante il flusso di pagamento. ## Attestazione e monitoraggio nella Sua app [#attestation-and-monitoring-in-your-app] L'attestazione e il monitoraggio non sono un componente da installare. Sono inclusi in Tapaya Accept SDK e nell'app plugin Tapaya Terminal, si avviano con `Accept.initialize()` e restano attivi per tutto il tempo in cui l'SDK è in esecuzione. Non esiste alcun flag di configurazione, alcuna possibilità di disattivarli né alcuna modalità che li allenti. Entrambe le parti devono superare i controlli in modo indipendente. La Sua app ospita l'SDK e l'SDK passa ogni pagamento con carta a Tapaya Terminal, che esegue la propria attestazione separatamente. Un dispositivo che soddisfa una parte ma non l'altra non può accettare pagamenti. ### Integrare l'attestazione nella Sua app [#integrating-attestation-into-your-app] | Obbligo | Come si traduce nel codice | | :---------------------------------------------- | :---------------------------------------------------------------------------------------------------------------- | | Inizializzare una sola volta, subito | `Accept.initialize(context, isProduction = true)` nella Sua classe `Application`. | | Dichiarare l'ambiente reale | `isProduction` segue il tipo di build, mai un valore scritto direttamente nel codice (hardcoded) per comodità. | | Mantenere Tapaya Terminal installato e attivato | Verifichi `Accept.plugin.isInstalled()`, poi `Accept.plugin.activateTerminal()`, prima di accettare un pagamento. | | Considerare definitivo un rifiuto | Lo comunichi all'esercente e si fermi. Non riprovi e non ripieghi su un altro percorso nel codice. | Per l'API completa alla base di ciascuno di questi punti, consulti [Integrazione dell'SDK mobile](../integration/sdk_integration). ### Distribuzione in una configurazione pronta per la produzione [#deploying-in-a-production-ready-configuration] Una build di produzione non deve essere di debug, non deve scrivere log e non deve indebolire la sicurezza del trasporto. L'SDK impone la maggior parte di questi vincoli da solo: una build di debug, o un debugger collegato, ne impedisce del tutto l'inizializzazione. | Impostazione | Sviluppo | Produzione | | :------------------------------------- | :------------------------------------------------------- | :------------------------------------------------------------------- | | `android:debuggable` | `true` | `false` | | `Accept.initialize(isProduction = …)` | `false` | `true` | | `Accept.setDebugLoggingEnabled(…)` | `true` | `false` | | Chiave di firma | keystore di debug | keystore di release | | R8 / ProGuard | disattivato | attivato, con le consumer rules dell'SDK intatte | | Configurazione della sicurezza di rete | può considerare attendibili le CA installate dall'utente | nessuna fiducia nelle CA dell'utente, nessun aggiramento del pinning | | Debug USB sul dispositivo | attivato | disattivato | Gestisca l'ambiente dalla build invece di modificarlo manualmente prima di un rilascio: ```kotlin Accept.initialize(context = this, isProduction = !BuildConfig.DEBUG) Accept.setDebugLoggingEnabled(BuildConfig.DEBUG) ``` Una build distribuita con il debug attivo, con il logging di debug lasciato acceso o con il certificate pinning aggirato è al di fuori della configurazione per cui Tapaya Accept è certificato, indipendentemente dal fatto che elabori ancora i pagamenti. Prima di ogni rilascio in produzione, verifichi ogni riga della tabella qui sopra. ### Prerequisiti della piattaforma [#platform-preconditions] Ognuno dei controlli descritti sopra dipende da una funzionalità del dispositivo host. La pagina [Dispositivi supportati](../getting-started/supported_devices#android-requirements) elenca ogni requisito, il motivo per cui serve all'attestazione e cosa succede quando manca. Due di questi influiscono sulla scelta dell'hardware: * **Android 11 è un limite minimo inderogabile.** I dispositivi con una versione precedente non possono eseguire l'SDK in alcun modo. Diversi modelli SoftPOS dedicati vengono ancora forniti con Android dalla 7 alla 9 senza possibilità di aggiornamento, quindi verifichi la versione del sistema operativo della specifica unità e non quella della famiglia di modelli. * **Google Mobile Services è facoltativo.** Dove i GMS sono presenti, l'SDK aggiunge ai propri controlli il verdetto della [Play Integrity API](#google-play-integrity-api). I terminali dedicati forniti senza GMS, comuni presso produttori come Sunmi e iMin, sono pienamente supportati. ### Quando un controllo non va a buon fine [#when-a-check-fails] Un controllo non superato è definitivo per quel dispositivo, non un errore temporaneo da riprovare. L'SDK si rifiuta di inizializzarsi, oppure si rifiuta di elaborare una transazione quando la violazione si presenta durante una sessione. Nulla nella Sua integrazione può scavalcare questo comportamento, e tentare di aggirarlo pone la Sua distribuzione al di fuori della configurazione certificata. Lo gestisca come un guasto irreparabile del dispositivo: comunichi all'esercente che il dispositivo non può accettare pagamenti e lo indirizzi all'assistenza. Non riprovi in un ciclo e non ripieghi su un percorso di pagamento diverso. ## Responsabilità dello sviluppatore [#developer-responsibilities] Anche se l'SDK svolge la maggior parte del lavoro, in qualità di integratore Lei deve garantire quanto segue: 1. **Non disattivi gli avvisi di sicurezza:** non tenti di aggirare l'SSL pinning o il rilevamento del root nelle build di produzione. 2. **Mantenga l'SDK aggiornato:** le patch di sicurezza vengono rilasciate regolarmente. Si assicuri che l'app utilizzi l'ultima versione di Tapaya Accept SDK. 3. **Offuschi la Sua app:** utilizzi ProGuard o R8 sul codice della Sua applicazione per evitare di esporre chiavi API o la logica che interagisce con l'SDK. ```kotlin title="proguard-rules.pro" # The Tapaya Accept SDK includes its own consumer rules, but ensure you do not strip them -keep class com.tapaya.** { *; } ``` ## Segnalare un incidente di sicurezza [#reporting-a-security-incident] Se scopre una vulnerabilità di sicurezza o sospetta un incidente di sicurezza che coinvolge Tapaya Accept SDK o la Sua integrazione, lo segnali in modo riservato come descritto in [Contatti](/support/contacts#security-issues). Indichi, se pertinenti, la versione dell'SDK interessata e le informazioni sul dispositivo.