Documentazione API Relazione tecnica - cybertech.eu
←
→
Trascrizione del contenuto della pagina
Se il tuo browser non visualizza correttamente la pagina, ti preghiamo di leggere il contenuto della pagina quaggiù
Documentazione API
Documentazione API
Relazione tecnica
03 2021
CYBERTECH S.R.L. SEDI GERMANIA
NORVEGIA
P.le Dell’Agricoltura, 24
SERBIA
00144 - Roma ROMA
SPAGNA
Tel: +39 0688816479 MILANO
SVEZIA
VERONA
Fax: +39 0699331512 SVIZZERA
BARI
TURCHIA
www.cybertech.eu UAE
Documentazione API Tutti i Diritti riservati. È espressamente vietato riprodurre, distribuire, pubblicare, riutilizzare anche parzialmente articoli, testi, immagini, applicazioni e metodologie del presente documento senza il previo permesso scritto rilasciato dalla società Cybertech S.r.l., ferma restando la possibilità di usufruire di tale materiale per uso interno della Società nel rispetto di quanto stabilito dal contratto di fornitura sottoscritto. Stato: Bozza Livello di classificazione: Confidenziale Pagina 2 di 38
Documentazione API
Indice generale
1. Introduzione .......................................................................................................................................... 5
Panoramica della soluzione .......................................................................................................... 5
Benefici soluzione OMNI4SPiD ..................................................................................................... 6
2. Autenticazione ...................................................................................................................................... 7
3. REST API ................................................................................................................................................ 8
Dashboard ..................................................................................................................................... 8
3.1.1. Total Request by IdP ............................................................................................................. 8
3.1.2. Error Details .......................................................................................................................... 9
3.1.3. Total errors.......................................................................................................................... 10
3.1.4. Total successful requests .................................................................................................... 11
3.1.5. Total failed requests ........................................................................................................... 12
3.1.6. Daily IdP requests................................................................................................................ 13
3.1.7. CPU usage (%) ..................................................................................................................... 15
3.1.8. Memory usage (%) .............................................................................................................. 16
3.1.9. Disk usage (%) ..................................................................................................................... 17
3.1.10. System daily info ................................................................................................................. 18
3.1.11. Service Uptime (%) .............................................................................................................. 22
3.1.12. System Uptime .................................................................................................................... 27
3.1.13. List Kibana Queries.............................................................................................................. 27
3.1.14. Run Kibana Query ............................................................................................................... 29
Services ....................................................................................................................................... 30
3.2.1. List Services ......................................................................................................................... 31
3.2.2. Call Action on Service .......................................................................................................... 32
4. Cybertech ............................................................................................................................................ 34
Chi siamo ..................................................................................................................................... 34
Il nostro approccio alla Cybersecurity......................................................................................... 35
La nostra proposta di valore ....................................................................................................... 35
Il nostro portafoglio di soluzioni ................................................................................................. 37
Certificazioni ISO ......................................................................................................................... 38
Stato: Bozza Livello di classificazione: Confidenziale Pagina 3 di 38Documentazione API Elenco Acronimi ACRONIMO DEFINIZIONE AGID Agenzia per l’Italia Ditale SPID Sistema Pubblico di Identità Digitale SAML Security Assertion Markup Language API Application Programming Interface XML Security Assertion Markup Language REST Representational State Transfer SOAP Simple Object Access Protocol PA Pubblica Amministrazione O4S OMNI4SPiD IdP Identity Provider Stato: Bozza Livello di classificazione: Confidenziale Pagina 4 di 38
Documentazione API
1. INTRODUZIONE
O4S Monitoring Console espone delle API di tipo REST che possono essere utilizzate, in sostituzione delle
componenti di Interfaccia Utente (UI), per accedere alle funzionalità del sistema ed ottenere direttamente
le informazioni di monitoraggio.
Le API REST per O4S Monitoring Console sono esposte utilizzando JSON over HTTP.
PANORAMICA DELLA SOLUZIONE
L'offerta OMNI4SPiD di Cybertech è una soluzione all-in-one per permettere una rapida
integrazione delle PA o delle Imprese quali Service Provider per fornire agli utenti tramite
l’utenza SPID, l’autenticazione e l’accesso alle risorse e ai servizi protetti.
Le Amministrazioni Pubbliche devono obbligatoriamente aderire al Sistema Pubblico di
Identità Digitale entro il 2021.
OMNI4SPiD nella sua formula appliance permette la riduzione del time-to-value, la continuità operativa
delle funzionalità in essere e la riduzione dei costi di ownership del prodotto.
Questa soluzione abilita gli utenti della PA o delle Imprese di riferimento ad utilizzare l’identità digitale
unica precedentemente registrata su SPID come strumento di accesso ai servizi online esposti dai fornitori
stessi e permette la propagazione di quest’identità digitale verso i servizi online esposti. Inoltre è pensata
per introdursi ed integrarsi all’interno dell’infrastruttura ICT del cliente riducendo al minimo gli impatti
funzionali e di gestione che questa introduzione comporta.
OMNI4SPiD (in seguito O4S) offre un servizio di autenticazione aggiuntivo e opzionale, mantenendo
inalterati i meccanismi di autenticazione del cliente, in modo da permettere l’accesso anche agli utenti
non in possesso di una credenziale SPID.
Stato: Bozza Livello di classificazione: Confidenziale Pagina 5 di 38Documentazione API
BENEFICI SOLUZIONE OMNI4SPID
Di seguito sono elencati alcune dei benefici chiave offerti dalla soluzione:
Configurazione e installazione completa a casa Cliente o come servizio Cloud: viene fornita una soluzione
end-to-end in grado di interfacciarsi con i sistemi di autenticazione del Cliente, incluso il collaudo del
processo di autenticazione con tutti gli Identity Provider.
Aggiornamento continuo alla normativa AgID: l’adeguamento ai cambiamenti normativi SPID imposti da
AgID è incluso nella soluzione O4S per tutta la sua durata contrattuale.
Conformità alle normative: sul tracciamento degli accessi
Meccanismo di federazione dinamico: la soluzione OMNI4SPID viene dinamicamente aggiornata con tutti
i nuovi Identity Provider SPID accreditati da AgID.
Semplificazione della gestione dei sistemi di autenticazione: il Cliente gestisce il proprio DB utenti senza
bisogno di conservazione delle credenziali SPID, in quanto depositate presso gli Identity Provider.
Eliminazione del rischio derivante dal furto delle credenziali utenti, in quanto depositate presso gli
Identity Provider.
Stato: Bozza Livello di classificazione: Confidenziale Pagina 6 di 38Documentazione API
2. AUTENTICAZIONE
Le API REST per O4S Monitoring Console sono accessibili previa autenticazione effettuata tramite API KEY,
ovvero attraverso una chiave simmetrica e quindi condivisa. Ad ogni utente di sistema o di terze parti
verrà assegnata una chiave, precedente creata, che comunque potrà essere in seguito revocata.
Per generare una APIKEY fare riferimento alla sezione SYSTEM_SETTINGS \ REST_API \ Create Api Key.
Ogni API KEY è definita dai seguenti campi:
CAMPO DESCRIZIONE
Key Name Si tratta di una stringa di caratteri utilizzata come riferimento
mnemonico. Il più delle volte questo nome corrisponde alla
persona o al sistema di terze parti cui è stata destinata la API
KEY.
Key La chiave viene auto-generata dal sistema. Ogni chiave è
memorizzata in formato hash per questioni di sicurezza. Il
momento della creazione sarà l’unico in cui sarà possibile
visualizzarla per intero per copiarla e memorizzarla in un luogo
sicuro.
Type Questo campo definisce il livello di accesso alle funzionalità e può
assumere i seguenti valori
[ Full | Reader ]
Per ognuno dei metodi riportati in seguito è specificato
contestualmente il livello di accesso necessario.
Expiration Questo campo definisce una data di scadenza oltre la quale la
API KEY non sarà più valida. E’ possibile lasciare vuoto questo
campo permettendo così alla API KEY di avere una durata
illimitata.
Il meccanismo di autenticazione basato su API KEY prevede che ogni chiamata alle API REST sia corredata
di un campo ApiKey presente nell’header HTTP. Di seguito un esempio di chiamata cURL:
curl -X GET 'http://localhost:8080/rest/api/get-services' \
-H 'Apikey: '
...
Stato: Bozza Livello di classificazione: Confidenziale Pagina 7 di 38Documentazione API
3. REST API
DASHBOARD
3.1.1. Total Request by IdP
• Livello di accesso: READER
Recupera il dettaglio delle richieste effettuate e raggruppate per Identity Provider. Il metodo accetta il
parametro days come query-string che rappresenta il numero degli ultimi giorni che si vogliono utilizzare
come periodo di osservazione.
GET /rest/api/tot-req-idp?days=
Di seguito un esempio di chiamata cURL:
curl -X GET 'http://localhost:8080/rest/api/tot-req-idp?days=30' \
-H 'accept: application/json' \
-H 'ApiKey: '
Specifica parametri:
• days: required, type int
Di seguito l’output prodotto:
{
"query": "TOT_REQ_IDP",
"start": "2021-02-26T23:00:00.000Z",
"end": "2021-03-29T15:47:21.736Z",
"data": [
{
"key": "Poste",
"doc_count": 2,
"DATA": {
"buckets": {
Stato: Bozza Livello di classificazione: Confidenziale Pagina 8 di 38Documentazione API
"Error": {
"doc_count": 0
},
"Response": {
"doc_count": 1
}
}
}
}
]
}
3.1.2. Error Details
• Livello di accesso: READER
Recupera il dettaglio degli errori delle richieste. Il metodo accetta il parametro days come query-string
che rappresenta il numero degli ultimi giorni che si vogliono utilizzare come periodo di osservazione.
GET /rest/api/err-det?days=
Specifica parametri:
• days: required, type int
Di seguito un esempio di chiamata cURL:
curl -X GET 'http://localhost:8080/rest/api/err-det?days=30' \
-H 'accept: application/json' \
-H 'ApiKey: '
Stato: Bozza Livello di classificazione: Confidenziale Pagina 9 di 38Documentazione API
Di seguito l’output prodotto:
{
"query": "ERR_DET",
"start": "2021-02-26T23:00:00.000Z",
"end": "2021-03-29T15:58:16.498Z",
"data": [
{
"key": "Errore Generico",
"doc_count": 1
},
{
"key": "L'utente ha negato il consenso all'utilizzo dei dati personali",
"doc_count": 1
},
{
"key": "Le credenziali dell'utente risultano bloccate",
"doc_count": 1
},
{
"key": "Ripetuta sottomissione di credenziali",
"doc_count": 1
}
]
}
3.1.3.Total errors
• Livello di accesso: READER
Recupera il numero totale di errori generati dalle richieste effettuare al sistema O4S. Il metodo accetta il
parametro days come query-string che rappresenta il numero degli ultimi giorni che si vogliono utilizzare
come periodo di osservazione.
Stato: Bozza Livello di classificazione: Confidenziale Pagina 10 di 38Documentazione API
GET /rest/api/tot-err
Specifica parametri:
• days: required, type int
Di seguito un esempio di chiamata cURL:
curl -X GET 'http://localhost:8080/rest/api/tot-err?days=30' \
-H 'accept: application/json' \
-H 'ApiKey: '
Di seguito l’output prodotto:
{
"query": "TOT_ERR",
"start": "2021-02-26T23:00:00.000Z",
"end": "2021-03-29T15:59:08.726Z",
"data": 1
}
3.1.4.Total successful requests
• Livello di accesso: READER
Recupera il totale delle richieste SPID andate a buon fine. Il metodo accetta il parametro days come query-
string che rappresenta il numero degli ultimi giorni che si vogliono utilizzare come periodo di osservazione.
GET /rest/api/tot-req-ok
Stato: Bozza Livello di classificazione: Confidenziale Pagina 11 di 38Documentazione API
Specifica parametri:
• days: required, type int
Di seguito un esempio di chiamata cURL:
curl -X GET 'http://localhost:8080/rest/api/tot-req-ok?days=30' \
-H 'accept: application/json' \
-H 'ApiKey: '
Di seguito l’output prodotto:
{
"query": "TOT_REQ_OK",
"start": "2021-02-27T23:00:00.000Z",
"end": "2021-03-30T09:48:05.677Z",
"data": 9
}
3.1.5.Total failed requests
• Livello di accesso: READER
Recupera il totale delle richieste SPID fallite. Il metodo accetta il parametro days come query-string che
rappresenta il numero degli ultimi giorni che si vogliono utilizzare come periodo di osservazione.
GET /rest/api/tot-req-ko
Specifica parametri:
• days: required, type int
Stato: Bozza Livello di classificazione: Confidenziale Pagina 12 di 38Documentazione API
Di seguito un esempio di chiamata cURL:
curl -X GET 'http://localhost:8080/rest/api/tot-req-ko?days=30' \
-H 'accept: application/json' \
-H 'ApiKey: '
Di seguito l’output prodotto:
{
"query": "TOT_REQ_KO",
"start": "2021-02-27T23:00:00.000Z",
"end": "2021-03-30T09:47:21.201Z",
"data": 3
}
3.1.6.Daily IdP requests
• Livello di accesso: READER
Recupera il totale giornaliero delle richieste SPID. Il metodo accetta il parametro days come query-string
che rappresenta il numero degli ultimi giorni che si vogliono utilizzare come periodo di osservazione.
GET /rest/api/req-idp-daily
Specifica parametri:
• days: required, type int
Di seguito un esempio di chiamata cURL:
curl -X GET 'http://localhost:8080/rest/api/req-idp-daily?days=30' \
-H 'accept: application/json' \
Stato: Bozza Livello di classificazione: Confidenziale Pagina 13 di 38Documentazione API
-H 'ApiKey: '
Di seguito l’output prodotto:
{
"query": "REQ_IDP_DAILY",
"start": "2021-02-26T23:00:00.000Z",
"end": "2021-03-29T16:05:54.028Z",
"data": [
{
"key_as_string": "2021-01-15T00:00:00.000+01:00",
"key": 1610665200000,
"doc_count": 1320,
"IDP": {
"doc_count_error_upper_bound": 0,
"sum_other_doc_count": 0,
"buckets": [
{
"key": "Poste",
"doc_count": 2,
"DATA": {
"buckets": {
"Error": {
"doc_count": 0
},
"Response": {
"doc_count": 1
}
}
}
}
]
}
},
{
Stato: Bozza Livello di classificazione: Confidenziale Pagina 14 di 38Documentazione API
"key_as_string": "2021-01-16T00:00:00.000+01:00",
"key": 1610838000000,
"doc_count": 0,
"IDP": {
"meta": [],
"doc_count_error_upper_bound": 0,
"sum_other_doc_count": 0,
"buckets": []
}
}
]
}
3.1.7.CPU usage (%)
• Livello di accesso: READER
Recupera la percentuale di utilizzo della risorsa CPU. Il metodo accetta il parametro days come query-
string che rappresenta il numero degli ultimi giorni che si vogliono utilizzare come periodo di osservazione.
GET /rest/api/cpu-perc
Specifica parametri:
• days: required, type int
Di seguito un esempio di chiamata cURL:
curl -X GET 'http://localhost:8080/rest/api/cpu-perc?days=30' \
-H 'accept: application/json' \
-H 'ApiKey: '
Stato: Bozza Livello di classificazione: Confidenziale Pagina 15 di 38Documentazione API
Di seguito l’output prodotto:
{
"query": "CPU_PERC",
"start": "2021-02-26T23:00:00.000Z",
"end": "2021-03-29T16:12:47.385Z",
"data": 0.04795250684249813
}
3.1.8.Memory usage (%)
• Livello di accesso: READER
Recupera la percentuale di utilizzo della risorsa Memoria. Il metodo accetta il parametro days come query-
string che rappresenta il numero degli ultimi giorni che si vogliono utilizzare come periodo di osservazione.
GET /rest/api/mem-perc
Specifica parametri:
• days: required, type int
Di seguito un esempio di chiamata cURL:
curl -X GET 'http://localhost:8080/rest/api/mem-perc?days=30' \
-H 'accept: application/json' \
-H 'ApiKey: '
Di seguito l’output prodotto:
{
Stato: Bozza Livello di classificazione: Confidenziale Pagina 16 di 38Documentazione API
"query": "MEM_PERC",
"start": "2021-02-26T23:00:00.000Z",
"end": "2021-03-29T16:13:52.407Z",
"data": 0.8185118477517259
}
3.1.9.Disk usage (%)
• Livello di accesso: READER
Recupera la percentuale di utilizzo della risorsa Disco. Il metodo accetta il parametro days come query-
string che rappresenta il numero degli ultimi giorni che si vogliono utilizzare come periodo di osservazione.
GET /rest/api/disk-perc
Specifica parametri:
• days: required, type int
Di seguito un esempio di chiamata cURL:
curl -X GET 'http://localhost:8080/rest/api/disk-perc?days=30' \
-H 'accept: application/json' \
-H 'ApiKey: '
Di seguito l’output prodotto:
{
"query": "DISK_PERC",
"start": "2021-02-26T23:00:00.000Z",
"end": "2021-03-29T16:14:58.231Z",
Stato: Bozza Livello di classificazione: Confidenziale Pagina 17 di 38Documentazione API
"data": 0.6434476776720761
}
3.1.10. System daily info
• Livello di accesso: READER
Recupera tutti i dettagli sull’utilizzo delle risorse e sull’uptime del sistema. Il metodo accetta il parametro
days come query-string che rappresenta il numero degli ultimi giorni che si vogliono utilizzare come
periodo di osservazione.
GET /rest/api/system-info-daily
Specifica parametri:
• days: required, type int
Di seguito un esempio di chiamata cURL:
curl -X GET 'http://localhost:8080/rest/api/system-info-daily?days=2' \
-H 'accept: application/json' \
-H 'ApiKey: '
Di seguito l’output prodotto:
{
"query": "SYSTEM_INFO_DAILY",
"start": "2021-03-27T23:00:00.000Z",
"end": "2021-03-29T16:17:41.406Z",
"data": [
{
"key_as_string": "2021-03-28T00:00:00.000+01:00",
Stato: Bozza Livello di classificazione: Confidenziale Pagina 18 di 38Documentazione API
"key": 1616886000000,
"doc_count": 840454,
"CPU_PERC": {
"buckets": {
"CPU_DATA": {
"doc_count": 840454,
"CPU_CORES": {
"value": 2
},
"CPU_SYSTEM": {
"value": 0.022028743961352657
},
"CPU_USER": {
"value": 0.07066243961352657
},
"CPU_USAGE": {
"value": 0.04634559178743961
}
}
}
},
"UPTIME_SYSTEM_PERC": {
"buckets": {
"UPTIME_DATA": {
"doc_count": 840454,
"MONITOR_DATA": {
"doc_count_error_upper_bound": 0,
"sum_other_doc_count": 0,
"buckets": [
{
"key": "up",
"doc_count": 13800,
"DATA": {
"value": 13800
}
},
{
"key": "down",
Stato: Bozza Livello di classificazione: Confidenziale Pagina 19 di 38Documentazione API
"doc_count": 2760,
"DATA": {
"value": 2760
}
}
]
},
"MONITOR_TOT": {
"value": 16560
},
"UPTIME": {
"value": 0.8333333333333334
}
}
}
},
"DISK_PERC": {
"value": 0.6556032608695652
},
"MEM_PERC": {
"value": 0.8037814009661837
}
},
{
"key_as_string": "2021-03-29T00:00:00.000+02:00",
"key": 1616968800000,
"doc_count": 668477,
"CPU_PERC": {
"buckets": {
"CPU_DATA": {
"doc_count": 668477,
"CPU_CORES": {
"value": 2
},
"CPU_SYSTEM": {
"value": 0.02518645611904039
},
"CPU_USER": {
Stato: Bozza Livello di classificazione: Confidenziale Pagina 20 di 38Documentazione API
"value": 0.08241147889462497
},
"CPU_USAGE": {
"value": 0.053798967506832676
}
}
}
},
"UPTIME_SYSTEM_PERC": {
"buckets": {
"UPTIME_DATA": {
"doc_count": 668477,
"MONITOR_DATA": {
"doc_count_error_upper_bound": 0,
"sum_other_doc_count": 0,
"buckets": [
{
"key": "up",
"doc_count": 10975,
"DATA": {
"value": 10975
}
},
{
"key": "down",
"doc_count": 2195,
"DATA": {
"value": 2195
}
}
]
},
"MONITOR_TOT": {
"value": 13170
},
"UPTIME": {
"value": 0.8333333333333334
}
Stato: Bozza Livello di classificazione: Confidenziale Pagina 21 di 38Documentazione API
}
}
},
"DISK_PERC": {
"value": 0.6716830601092897
},
"MEM_PERC": {
"value": 0.8034346241457859
}
}
]
}
3.1.11. Service Uptime (%)
Restituisce la disponibilità (%) di ogni singolo servizio monitorato che compone il sistema. Il metodo
accetta il parametro days come query-string che rappresenta il numero degli ultimi giorni che si vogliono
utilizzare come periodo di osservazione.
GET /rest/api/uptime-services-perc?days=
Parametri:
• days: required, type int
Di seguito un esempio di chiamata cURL:
curl -X GET 'http://localhost:8080/rest/api/uptime-services-perc?days=30' \
-H 'accept: application/json' \
-H 'ApiKey: '
Di seguito l’output prodotto:
Stato: Bozza Livello di classificazione: Confidenziale Pagina 22 di 38Documentazione API
{
"query": "UPTIME_SERVICES_PERC",
"start": "2021-02-27T23:00:00.000Z",
"end": "2021-03-30T08:20:02.996Z",
"data": [
{
"key": "o4s-odfe-kibana",
"doc_count": 12616,
"MONITOR_DATA": {
"doc_count_error_upper_bound": 0,
"sum_other_doc_count": 0,
"buckets": [
{
"key": "up",
"doc_count": 12616,
"DATA": {
"value": 12616
}
}
]
},
"MONITOR_TOT": {
"value": 12616
},
"UPTIIME": {
"value": 1
}
},
{
"key": "o4s-odfe-node1",
"doc_count": 12616,
"MONITOR_DATA": {
"doc_count_error_upper_bound": 0,
"sum_other_doc_count": 0,
"buckets": [
{
"key": "up",
Stato: Bozza Livello di classificazione: Confidenziale Pagina 23 di 38Documentazione API
"doc_count": 12616,
"DATA": {
"value": 12616
}
}
]
},
"MONITOR_TOT": {
"value": 12616
},
"UPTIIME": {
"value": 1
}
},
{
"key": "o4s_shibboleth",
"doc_count": 12616,
"MONITOR_DATA": {
"doc_count_error_upper_bound": 0,
"sum_other_doc_count": 0,
"buckets": [
{
"key": "down",
"doc_count": 12616,
"DATA": {
"value": 12616
}
}
]
},
"MONITOR_TOT": {
"value": 12616
}
},
{
"key": "o4s_wildfly1",
"doc_count": 12616,
"MONITOR_DATA": {
Stato: Bozza Livello di classificazione: Confidenziale Pagina 24 di 38Documentazione API
"doc_count_error_upper_bound": 0,
"sum_other_doc_count": 0,
"buckets": [
{
"key": "up",
"doc_count": 12616,
"DATA": {
"value": 12616
}
}
]
},
"MONITOR_TOT": {
"value": 12616
},
"UPTIIME": {
"value": 1
}
},
{
"key": "o4s_wildfly2",
"doc_count": 12616,
"MONITOR_DATA": {
"doc_count_error_upper_bound": 0,
"sum_other_doc_count": 0,
"buckets": [
{
"key": "up",
"doc_count": 12616,
"DATA": {
"value": 12616
}
}
]
},
"MONITOR_TOT": {
"value": 12616
},
Stato: Bozza Livello di classificazione: Confidenziale Pagina 25 di 38Documentazione API
"UPTIIME": {
"value": 1
}
},
{
"key": "o4s-cnsl-webapp",
"doc_count": 10923,
"MONITOR_DATA": {
"doc_count_error_upper_bound": 0,
"sum_other_doc_count": 0,
"buckets": [
{
"key": "up",
"doc_count": 10919,
"DATA": {
"value": 10919
}
},
{
"key": "down",
"doc_count": 4,
"DATA": {
"value": 4
}
}
]
},
"MONITOR_TOT": {
"value": 10923
},
"UPTIIME": {
"value": 0.9996338002380298
}
}
]
}
Stato: Bozza Livello di classificazione: Confidenziale Pagina 26 di 38Documentazione API
3.1.12. System Uptime
Restituisce la disponibilità (%) dell’intero sistema, calcolato a partire dalla disponibilità dei singoli servizi
che lo compongono. Il metodo accetta il parametro days come query-string che rappresenta il numero
degli ultimi giorni che si vogliono utilizzare come periodo di osservazione.
GET /rest/api/uptime-system-perc?days=
Specifica parametri:
• days: required, type int
Di seguito un esempio di chiamata cURL:
curl -X GET 'http://localhost:8080/rest/api/uptime-system-perc?days=30' \
-H 'accept: application/json' \
-H 'ApiKey: '
Di seguito l’output prodotto:
{
"query": "UPTIME_SYTEM_PERC",
"start": "2021-02-27T23:00:00.000Z",
"end": "2021-03-30T08:20:45.174Z",
"data": 0.8294643822289482
}
3.1.13. List Kibana Queries
• Livello di accesso: READER
Stato: Bozza Livello di classificazione: Confidenziale Pagina 27 di 38Documentazione API
Questo metodo recupera i nomi, utilizzati come riferimenti, di tutte le query disponibili che è possibile
utilizzare con il metodo `run-query`. Il metodo non accetta parametri.
GET /rest/api/query-names
Di seguito un esempio di chiamata cURL:
curl -X GET 'http://localhost:8080/rest/api/query-names' \
-H 'accept: application/json' \
-H 'ApiKey: '
Di seguito l’output prodotto:
[
{
"name": "TOT_REQ_OK",
"descr": "Totale richieste SPID"
},
{
"name": "TOT_REQ_KO",
"descr": "Totale richieste SPID Fallite"
},
{
"name": "TOT_ERR",
"descr": "Totale Errori"
},
{
"name": "CPU_PERC",
"descr": "CPU (%)"
},
{
"name": "MEM_PERC",
Stato: Bozza Livello di classificazione: Confidenziale Pagina 28 di 38Documentazione API
"descr": "MEMORY (%)"
},
{
"name": "DISK_PERC",
"descr": "DISK (%)"
},
{
"name": "UPTIME_SYSTEM_PERC",
"descr": "UPTIME (%)"
},
{
"name": "TOT_REQ_IDP",
"descr": "Dettaglio richieste per Identity Provider"
},
{
"name": "ERR_DET",
"descr": "Dettaglio errori"
},
{
"name": "REQ_IDP_DAILY",
"descr": "Richieste giornaliere"
},
{
"name": "SYSTEM_INFO_DAILY",
"descr": "Dettaglio giornaliero risorse del sistema"
},
{
"name": "UPTIME_SERVICES_PERC",
"descr": "UPTIME SERVICES (%)"
}
]
3.1.14. Run Kibana Query
• Livello di accesso: READER
Stato: Bozza Livello di classificazione: Confidenziale Pagina 29 di 38Documentazione API
Recupera le metriche per la richiesta specificata. Il metodo accetta il parametro queryName che identifica
la query da eseguire e il parametro days che rappresenta il numero degli ultimi giorni che si vogliono
utilizzare come periodo di osservazione. Entrambi i parametri vengono passati come query-string.
GET /rest/api/run-query?queryName=&days=
Specifica parametri:
• queryName: required, type string
• days: required, type int
Di seguito un esempio di chiamata cURL:
curl -X GET \
'http://localhost:8080/rest/api/run-query?queryName=UPTIME_SYSTEM_PERC&days=30' \
-H 'accept: application/json' \
-H 'ApiKey: '
Di seguito l’output prodotto:
{
"query": "UPTIME_SYSTEM_PERC",
"start": "2021-02-26T23:00:00.000Z",
"end": "2021-03-29T17:54:48.355Z",
"data": 0.8333333333333334
}
SERVICES
Stato: Bozza Livello di classificazione: Confidenziale Pagina 30 di 38Documentazione API
3.2.1.List Services
• Livello di accesso: FULL
Recupera tutti i servizi disponibili il cui stato può essere gestito con il metodo `service-action`. Il metodo
non accetta parametri.
GET /rest/api/get-services
Di seguito un esempio di chiamata cURL:
curl -X GET 'http://localhost:8080/rest/api/get-services' \
-H 'accept: application/json' \
-H 'ApiKey: '
Di seguito l’output prodotto:
{
"services": [
"shibboleth",
"wildfly1",
"elasticsearch",
"kibana",
"logstash",
"heartbeat",
"metricbeat",
"filebeat"
]
Stato: Bozza Livello di classificazione: Confidenziale Pagina 31 di 38Documentazione API
3.2.2.Call Action on Service
• Livello di accesso: FULL
Esegue l’azione richiesta per lo specifico servizio. Il metodo accetta il parametro service che identifica il
servizio da gestire e il parametro action che indica l’azione da eseguire. Entrambi i parametri vengono
passati come query-string.
GET /rest/api/service-action?service=&action=
Specifica parametri:
• service: required, type string
• action: required, type string, values [ start | stop | status | restart | reload | reloadorrestart |
journal ]
Di seguito un esempio di chiamata cURL:
curl -X GET \
'http://localhost:8080/rest/api/service-action?service=shibboleth&action=status' \
-H 'accept: application/json' \
-H 'ApiKey: '
Di seguito l’output prodotto:
{
"status": "active"
}
Tutte le azioni, ad eccezione di `status` e `journal` restituiscono come risultato OK o Fail se si verifica un
errore. Al momento tutti i servizi/componenti della soluzione O4S Monitoring Console non dispongono
Stato: Bozza Livello di classificazione: Confidenziale Pagina 32 di 38Documentazione API
dei metodi `reload` e `journal`: il primo ritornerà come risultato sempre Fail mentre il secondo restituirà
un array vuoto [].
Per l’azione `status` le possibili risposte sono le seguenti:
• active: servizio avviato
• reloading: in fase di reload
• inactive: servizio fermo con codice di uscita
• failed: servizio fermo
• activating: start avviato
• deactivating: stop avviato
• not-found: servizio inesistente
Stato: Bozza Livello di classificazione: Confidenziale Pagina 33 di 38Documentazione API
4. CYBERTECH
CHI SIAMO
Cybertech è uno dei più importanti player europei nell’ambito della
sicurezza informatica, con sede legale a Roma, e altre due sedi
operative italiane a Milano e Verona. A livello internazionale
siamo presenti in Spagna, Svizzera, Germania, Svezia,
Norvegia, Serbia e Turchia. Da gennaio 2019 Cybertech fa
parte del Gruppo Engineering, leader nella Digital
Transformation, diventandone il centro di eccellenza per la
Cybersecurity.
Con oltre 300 specialisti, possediamo un unico mix di
esperienze, risorse e tecnologie per proteggere la
crescita del vostro business nell’era della Digital
Transformation. Seguiamo da più di 10 anni progetti end-to-end di Cybersecurity in oltre 20 paesi
nell’area EMEA.
La nostra missione è proteggere la crescita sicura delle aziende, minimizzando i rischi informatici derivanti
dalla Digital Transformation. Chi sceglie il nostro approccio alla Cybersecurity potrà concentrarsi sullo
sviluppo del proprio business, avendo al proprio fianco un partner in grado di formare i dipendenti,
controllare le reti, salvaguardare i dati e prevenire le minacce informatiche, prima che abbiano un impatto
per l’azienda.
La profonda specializzazione, combinata con l’approccio olistico alla Cybersecurity (Tabella 1.), ci
permette di proteggere gli Asset digitali e i flussi informativi, con l’obiettivo di creare una struttura di
sicurezza flessibile e in grado di adattarsi alle mutevoli e sofisticate minacce che il mondo del Cloud, del
mobile e del social computing pongono alle infrastrutture, ai dati ed alle applicazioni aziendali critiche.
Offriamo inoltre soluzioni di Managed Security Services (MSS), Security Operation Center (SOC) e
Computer Security Incident Response Team (CSIRT) attraverso la Control Room Cybertech (certificata ISO
27001).
Figura 1 - Approccio olistico alla Cybersecurity
Stato: Bozza Livello di classificazione: Confidenziale Pagina 34 di 38Documentazione API
IL NOSTRO APPROCCIO ALLA CYBERSECURITY
Dal punto di vista del business, il nostro approccio alla Cybersecurity si basa su tre pilastri:
• Governo delle identità digitali, per anticipare la compliance e controllare adeguatamente gli
accessi ad applicazioni e dati fondamentali, allineando la funzione Audit con le Line of business
(LOB) e le esigenze del reparto IT;
• Blocco degli attacchi-cyber, per intercettare e fermare le minacce avanzate, persistenti e interne,
sfruttando nelle nostre soluzioni di sicurezza l’Intelligenza Artificiale e un’efficace automazione,
per un’organizzazione ordinata di processi IR (Informative References) e di ispezioni legali;
• Salvaguardia dei dati all’interno dell’ecosistema aziendale (B2E, B2C, B2B), per governarne il
rischio dei dati, proteggerne il brand e abilitarne il business digitale.
Questi tre pilastri offrono un’adeguata comprensione e mitigazione del rischio cyber con l’applicazione di
contromisure prioritarie sia in ambito organizzativo che tecnologico. In questo modo le aziende sono in
grado di:
• intraprendere un percorso di Digital Transformation più sicuro;
• garantire l’affidabilità delle attività aziendali, assicurando allo stesso tempo la riservatezza, la
disponibilità, l’integrità e la sicurezza delle risorse informative insieme a coerenti programmi
Business Continuity e Disaster Recovery;
• favorire l’adozione di soluzioni in Cloud, per ottenere una crescita aziendale, il rafforzamento del
brand, competitività e maggiore elasticità;
• mantenere una continua e verificabile conformità normativa.
LA NOSTRA PROPOSTA DI VALORE
La nostra proposta di valore trae origine da una visione olistica della Cybersecurity che abbiamo maturato
grazie all’esperienza su progetti in vari domini.
L'ampiezza e la profondità della nostra specializzazione è in grado di supportare e guidare le aziende verso
il raggiungimento di concreti risultati di business, come ad esempio:
▪ Garantire un'adeguata protezione delle infrastrutture, dei dati e delle applicazioni aziendali
contro le possibili minacce legate all’utilizzo dei servizi in Cloud e delle piattaforme mobile,
rimanendo sempre aggiornati sull’evoluzione dei rischi informatici;
▪ Ottenere la visibilità dello stato di sicurezza informatica in tutta l'azienda, reagire e mitigare
rapidamente gli impatti degli incidenti di sicurezza;
▪ Garantire conformità a policy e normative di riferimento (GDPR);
Stato: Bozza Livello di classificazione: Confidenziale Pagina 35 di 38Documentazione API
▪ Difendere la conoscenza e la proprietà intellettuale dell’azienda, proteggendola dalla pirateria
informatica e dal furto di informazioni IT privilegiate;
▪ Ridurre la complessità di gestione del Security Operation Center (SOC);
▪ Stabilire una relazione di fiducia con gli utenti, migliorandone l’esperienza e garantendo l’accesso
sicuro a dati ed applicazioni, nel rispetto delle policy e dei ruoli aziendali;
▪ Migliorare la soddisfazione dei clienti attraverso soluzioni mobile agili, performanti e sicure;
▪ Responsabilizzare i dipendenti all’uso appropriato di strumenti di collaborazione, siano essi in
Cloud o mobile, per mitigare il rischio di perdita di dati e raggiungere la produttività desiderata.
Nel corso degli anni abbiamo stabilito solide partnership tecnologiche con leader di mercato, tra cui IBM,
CA, HP, RSA, NetIQ, Splunk, Symantec, McAfee, SafeNet, CheckPoint, CrossIdeas, ASG.
La nostra Architettura di Riferimento
Le sfide della trasformazione verso il digitale richiedono un approccio alla Cybersecurity:
multidimensionale, trasversale a diversi settori e in grado di mettere in campo competenze basate su
tecnologie che combinino tecniche comprovate di rilevamento delle minacce con funzionalità di
protezione avanzata.
Cybertech utilizza una struttura logica basata su una architettura integrata, che riflette la nostra visione e
le nostre specializzazioni. (Tabella 2.)
Figura 2 - Architettura logica di riferimento
Stato: Bozza Livello di classificazione: Confidenziale Pagina 36 di 38Documentazione API
IL NOSTRO PORTAFOGLIO DI SOLUZIONI
Cybertech, grazie alla capacità di analisi di settore e industria, è in grado di progettare, implementare,
operare e supportare soluzioni che coniugano l’innovazione con la realtà di business nelle seguenti aree:
Security Governance, Risk e Compliance, è un unico set di controlli per monitorare i principali
processi di business e sulle procedure di governance. Questo approccio unitario e centralizzato
ha il vantaggio di ridurre la ridondanza e può essere applicato a livello macro, su tutta l’azienda,
o concentrarsi su un singolo processo.
Identity & Access Administration and Governance, è l’insieme dei processi e delle tecnologie
per l’amministrazione, il provisioning, la governance e gli analytics delle identità e del controllo
degli accessi ai sistemi ed alle applicazioni. Comprende la gestione del ciclo di vita delle identità:
creazione, mantenimento e revoca di profili e credenziali. Governa il processo di richiesta di accesso,
approvazione, certificazione, calcolo del rischio e separazione delle funzioni (SOD).
Security Intelligence e Analytics, permette di analizzare enormi quantità di dati, applicando le
funzioni di business intelligence a tutti i livelli dello strato tecnologico. Nelle sue componenti
infrastrutturali, applicative e di dati, fornisce le informazioni contestuali che aiutano a
identificare le vulnerabilità in tempo reale. Consente di registrare e certificare gli eventi di sicurezza sulla
base degli SLA (Service Level Agreement) oltre che supportare analisi forensi e di conformità normativa.
Network and Virtual Infrastructure Protection, un insieme di servizi e tecnologie hardware e
software che garantiscono la sicurezza delle reti e delle infrastrutture fisiche con particolare
attenzione alle reti virtuali.
Security Assessment, è la metodologia sicura, senza impatti e ben collaudata per individuare
vulnerabilità e rischi di sicurezza IT. L'obiettivo è quello di garantire che i controlli di sicurezza
siano integrati nelle infrastrutture, nelle applicazioni e nei percorsi critici di business. A fronte
degli scenari di Recovery Remediation presentati, i responsabili potranno decidere come meglio allocare
le risorse e definire le azioni necessarie.
Workstation, end-point & mobile security, definisce come proteggere gli end-point e rendere
tutte le infrastrutture più forti e sicure, a partire da qualsiasi dispositivo (desktop, laptop, tablet
o smartphone). Sono inclusi i servizi di sviluppo di mobile APP attraverso MADP (Mobile App
Development Platform) e l’implementazione di tecnologie di Enterprise Mobility Management.
IT Service & Asset Management, si basa su un framework ITIL v3 (IT Infrastructure Library) il
quale consente di progettare e fornire soluzioni integrate di vari servizi come, Service Fullfillment
(delivery e automazione processi di service desk), Service Assurance (disponibilità e prestazioni
dei servizi IT), Enterprise Asset Management, nonché il Property & Facility Management.
Stato: Bozza Livello di classificazione: Confidenziale Pagina 37 di 38Documentazione API
CERTIFICAZIONI ISO
Al fine di garantire alle aziende efficaci servizi di qualità e di sicurezza delle informazioni, implementiamo
un sistema di gestione integrato e certificato dall’Ente RINA Services secondo le norme ISO 9001:2015 e
ISO 27001:2013 per il seguente ambito di applicazione:
“Progettazione ed erogazione di servizi di:
▪ Consulenza informatica relativa alle integrazioni software per i sistemi informativi e per la
sicurezza.
▪ Sviluppo, gestione e manutenzione delle infrastrutture tecnologiche IT.
▪ Di tipo MSS (Managed Security Services): Identity Access Governance and Management, Network
Security, Monitoraggio dei sistemi di sicurezza, Vulnerability Assessment and Penetration Test,
Ethical Hacking, SOC Management, Incident Management security Advisory.
▪ Digital Forensic.
Progettazione, produzione, installazione e manutenzione di prodotti software [Settori di riferimento: EA
33, EA 35].”
Stato: Bozza Livello di classificazione: Confidenziale Pagina 38 di 38Puoi anche leggere
