Requisiti per la qualificazione di servizi SaaS: Requisiti delle soluzioni SaaS

Ciò premesso, AgID, come indicato all’art. 4 Circolare, ha classificato i requisiti per la qualificazione delle soluzioni SaaS come segue:

  • Requisiti preliminari (RP),
  • Requisiti organizzativi (RO),
  • Requisiti specifici.

Continua a leggere su: http://cloud-pa.readthedocs.io/it/latest/circolari/SaaS/allegato_docs/requisiti-delle-soluzioni-saas.html

OSSERVAZIONI ASSOSOFTWARE

Nel modello architetturale “Scalable SaaS application” si parla di scalabilità delle istanze applicative. Come la grafica lascia intendere, la scalabilità è richiesta anche sulla componente database oppure soltanto sulle componenti applicative (BL, UI, API, …)?

Con il requisito RP1 si intende che la responsabilità di “autoscaling” è data alla soluzione SaaS quando tipicamente sono competenze delegate ad un layer sottostante (PaaS). I servizi infatti si ritroverebbero a dover interagire con le API della piattaforma Cloud nei momenti di maggior carico. Come occorre considerare tali requisiti in caso di adozione di PaaS con questo tipo di caratteristiche?

Sul requisito RP2 inerente ai KPI, l’Acquirente è interessato a tutti quegli indicatori che possono impattare sul’erogazione del servizio. Alcune delle metriche citate relative al consumo di risorse cloud (computazionali, storage, rete, …) potrebbero non essere direttamente legate alle performance o al costo della fornitura (fortemente dipendente dai contratti). In questi casi vanno comunque considerata l’esposizione di metriche sull’utilizzo di risorse computazionali?

Nel requisito RP3 viene chiesto di poter accedere al “logging/tracing relativo all’esecuzione di processi di sistema”. Cosa si intende precisamente? Si fa riferimento al logging della stessa soluzione SaaS? In ambito Cloud SPC/PSN sono previte API per l’accesso a questo genere di servizi?

RS7 - Il Fornitore SaaS deve mettere in atto misure di network e domain isolation (firewall, ACL, controller di dominio) per mantenere l’isolamento tra i diversi domini applicativi.
Nell’ambito delle funzionalità messe a disposizione dal Cloud SPC, o comunque dettagliate nei requisiti per i Cloud per le PA, chi si occupa del software quali meccanismi ha a disposizione per controllare elementi infrastrutturali come quelli citati in questo requisito (firewall) e, se vogliamo, anche nei requisiti RS6 e RS8?

Il requisito RPS8 non è riportato direttamente tra i requisiti di Performance e Scalabilità. Tuttavia è riportato negli impegni contrattuali al punto CL12. E’ da intendersi come un refuso? Tra l’altro nella definizione RPS7 fa riferimento alla multi-tenancy mentre sempre al punto CL12 è scritto in modo diverso. Quale versione è corretta?

RS9 - …devono essere inclusi meccanismi per bloccare il traffico di rete da e verso URL presenti in una blacklist…
Il traffico di rete non ha un URL di provenienza, casomai un indirizzo IP, e più in generale “traffico di rete” e “URL” afferiscono a livelli dello stack ISO/OSI differenti. Se posso dare un suggerimento, riformulerei in maniera differente.
RS14 - Il Fornitore SaaS deve garantire che non si possano verificare abusi nell’uso delle funzionalità dell’applicazione e nell’accesso ai dati (eventualmente in grado di compromettere la sicurezza)
Dal momento che è a carico del fornitore SaaS occuparsi della sicurezza dell’intera supply chain relativa all’applicazione, e che purtroppo gli 0-day esistono (https://it.wikipedia.org/wiki/0-day), la garanzia dell’assenza di qualunque possibilità, seppur remota, che un malintenzionato con sufficienti risorse e conoscenze possa effettuare degli abusi mi sembra utopica. Sbaglio?

Riguardo a RIP1, non sono ammesse API come quelle graphql.org di facebook?

Per reversibilità si intende dover girare sul lotto1 ?

Si richiede di fornire un account di test per il SaaS di produzione e basta un account di test su un server test ?

RIP5 a che livello bisogna scendere per effettuare un log in grado di garantire la non ripudiabilità? Indicare chi ha fatto cosa e quando, correlato di tutti i parametri importanti, oppure basta loggare l’endpoint chiamato con lo status HTTP della risposta?