Translated ['src/pentesting-cloud/aws-security/aws-basic-information/REA

This commit is contained in:
Translator
2025-02-10 23:49:50 +00:00
parent 9096849d05
commit eb8a4062d7
33 changed files with 514 additions and 810 deletions

View File

@@ -21,7 +21,7 @@ Pertanto, ci sono **due tipi di account in un'organizzazione** (stiamo parlando
- Rimuovere account dall'organizzazione
- Gestire inviti
- Applicare politiche a entità (root, OU o account) all'interno dell'organizzazione
- Abilitare l'integrazione con i servizi AWS supportati per fornire funzionalità di servizio a tutti gli account dell'organizzazione.
- Abilitare l'integrazione con i servizi AWS supportati per fornire funzionalità di servizio a tutti gli account nell'organizzazione.
- È possibile accedere come utente root utilizzando l'email e la password utilizzate per creare questo account/organizzazione root.
L'account di gestione ha le **responsabilità di un account pagatore** ed è responsabile del pagamento di tutte le spese accumulate dagli account membri. Non puoi cambiare l'account di gestione di un'organizzazione.
@@ -40,7 +40,7 @@ aws organizations create-organizational-unit --parent-id r-lalala --name TestOU
```
### Service Control Policy (SCP)
Una **service control policy (SCP)** è una politica che specifica i servizi e le azioni che gli utenti e i ruoli possono utilizzare negli account che la SCP influisce. Le SCP sono **simili alle politiche di autorizzazione IAM** tranne per il fatto che **non concedono alcuna autorizzazione**. Invece, le SCP specificano le **autorizzazioni massime** per un'organizzazione, un'unità organizzativa (OU) o un account. Quando si allega una SCP alla radice dell'organizzazione o a un'OU, la **SCP limita le autorizzazioni per le entità negli account membri**.
Una **service control policy (SCP)** è una politica che specifica i servizi e le azioni che gli utenti e i ruoli possono utilizzare negli account che la SCP influisce. Le SCP sono **simili alle politiche di autorizzazione IAM** tranne per il fatto che **non concedono alcuna autorizzazione**. Invece, le SCP specificano le **autorizzazioni massime** per un'organizzazione, un'unità organizzativa (OU) o un account. Quando si allega una SCP alla radice dell'organizzazione o a un'OU, le **SCP limitano le autorizzazioni per le entità negli account membri**.
Questo è l'UNICO modo in cui **anche l'utente root può essere bloccato** dal fare qualcosa. Ad esempio, potrebbe essere utilizzato per impedire agli utenti di disabilitare CloudTrail o di eliminare i backup.\
L'unico modo per bypassare questo è compromettere anche il **master account** che configura le SCP (il master account non può essere bloccato).
@@ -57,7 +57,7 @@ Esempi di SCP:
essere disabilitati
- Negare ai ruoli di sicurezza/risposta agli incidenti di essere eliminati o
- Negare ai ruoli di sicurezza/riposta agli incidenti di essere eliminati o
modificati.
@@ -90,43 +90,43 @@ IAM è il servizio che ti permetterà di gestire **Autenticazione**, **Autorizza
IAM può essere definito dalla sua capacità di gestire, controllare e governare i meccanismi di autenticazione, autorizzazione e controllo degli accessi delle identità alle tue risorse all'interno del tuo account AWS.
### [Utente root dell'account AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html) <a href="#id_root" id="id_root"></a>
### [AWS account root user](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html) <a href="#id_root" id="id_root"></a>
Quando crei per la prima volta un account Amazon Web Services (AWS), inizi con un'unica identità di accesso che ha **accesso completo a tutti** i servizi e le risorse AWS nell'account. Questo è l'utente _**root**_ dell'account AWS e viene accesso effettuando il login con **l'indirizzo email e la password che hai usato per creare l'account**.
Quando crei per la prima volta un account Amazon Web Services (AWS), inizi con un'identità di accesso singolo che ha **accesso completo a tutti** i servizi e le risorse AWS nell'account. Questo è l'_**utente root**_ dell'account AWS e viene accesso effettuando il login con **l'indirizzo email e la password che hai usato per creare l'account**.
Nota che un nuovo **utente admin** avrà **meno permessi dell'utente root**.
Da un punto di vista della sicurezza, è consigliato creare altri utenti ed evitare di utilizzare questo.
### [Utenti IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html) <a href="#id_iam-users" id="id_iam-users"></a>
### [IAM users](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html) <a href="#id_iam-users" id="id_iam-users"></a>
Un _utente_ IAM è un'entità che crei in AWS per **rappresentare la persona o l'applicazione** che lo utilizza per **interagire con AWS**. Un utente in AWS consiste in un nome e credenziali (password e fino a due chiavi di accesso).
Quando crei un utente IAM, gli concedi **permessi** rendendolo un **membro di un gruppo di utenti** che ha politiche di permesso appropriate allegate (consigliato), o **allegando direttamente le politiche** all'utente.
Quando crei un utente IAM, gli concedi **permessi** rendendolo un **membro di un gruppo di utenti** che ha politiche di permesso appropriate collegate (consigliato), o **allegando direttamente le politiche** all'utente.
Gli utenti possono avere **MFA abilitato per il login** attraverso la console. I token API degli utenti con MFA abilitato non sono protetti da MFA. Se desideri **limitare l'accesso delle chiavi API di un utente utilizzando MFA**, devi indicare nella politica che per eseguire determinate azioni è necessaria la presenza di MFA (esempio [**qui**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html)).
#### CLI
- **ID chiave di accesso**: 20 caratteri alfanumerici casuali in maiuscolo come AKHDNAPO86BSHKDIRYT
- **ID chiave di accesso segreta**: 40 caratteri casuali in maiuscolo e minuscolo: S836fh/J73yHSb64Ag3Rkdi/jaD6sPl6/antFtU (Non è possibile recuperare gli ID delle chiavi di accesso segrete perse).
- **Access Key ID**: 20 caratteri alfanumerici casuali in maiuscolo come AKHDNAPO86BSHKDIRYT
- **Secret access key ID**: 40 caratteri casuali in maiuscolo e minuscolo: S836fh/J73yHSb64Ag3Rkdi/jaD6sPl6/antFtU (Non è possibile recuperare le chiavi di accesso segrete perse).
Ogni volta che hai bisogno di **cambiare la chiave di accesso**, questo è il processo che dovresti seguire:\
&#xNAN;_&#x43;rea una nuova chiave di accesso -> Applica la nuova chiave al sistema/applicazione -> contrassegna quella originale come inattiva -> Testa e verifica che la nuova chiave di accesso funzioni -> Elimina la vecchia chiave di accesso_
Ogni volta che hai bisogno di **cambiare la Access Key**, questo è il processo che dovresti seguire:\
_Crea una nuova chiave di accesso -> Applica la nuova chiave al sistema/applicazione -> contrassegna quella originale come inattiva -> Testa e verifica che la nuova chiave di accesso funzioni -> Elimina la vecchia chiave di accesso_
### MFA - Multi Factor Authentication
Viene utilizzato per **creare un fattore aggiuntivo per l'autenticazione** oltre ai tuoi metodi esistenti, come la password, creando quindi un livello di autenticazione multi-fattore.\
Puoi utilizzare un **applicazione virtuale gratuita o un dispositivo fisico**. Puoi utilizzare app come google authentication gratuitamente per attivare un MFA in AWS.
Le politiche con condizioni MFA possono essere allegate ai seguenti:
Le politiche con condizioni MFA possono essere collegate ai seguenti:
- Un utente o gruppo IAM
- Una risorsa come un bucket Amazon S3, una coda Amazon SQS o un argomento Amazon SNS
- La politica di fiducia di un ruolo IAM che può essere assunto da un utente
Se desideri **accedere tramite CLI** a una risorsa che **controlla per MFA**, devi chiamare **`GetSessionToken`**. Questo ti darà un token con informazioni su MFA.\
Nota che **le credenziali di `AssumeRole` non contengono queste informazioni**.
Nota che le credenziali di **`AssumeRole` non contengono queste informazioni**.
```bash
aws sts get-session-token --serial-number <arn_device> --token-code <code>
```
@@ -136,14 +136,14 @@ Come [**indicato qui**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_cred
Un [gruppo di utenti IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html) è un modo per **allegare politiche a più utenti** contemporaneamente, il che può semplificare la gestione delle autorizzazioni per quegli utenti. **I ruoli e i gruppi non possono far parte di un gruppo**.
Puoi allegare una **politica basata sull'identità a un gruppo di utenti** in modo che tutti gli **utenti** nel gruppo di utenti **ricevano le autorizzazioni della politica**. Non puoi identificare un **gruppo di utenti** come un **`Principal`** in una **politica** (come una politica basata sulle risorse) perché i gruppi si riferiscono alle autorizzazioni, non all'autenticazione, e i principal sono entità IAM autenticate.
Puoi allegare una **politica basata sull'identità a un gruppo di utenti** in modo che tutti gli **utenti** nel gruppo di utenti **ricevano le autorizzazioni della politica**. Non puoi **identificare un gruppo di utenti** come un **`Principal`** in una **politica** (come una politica basata sulle risorse) perché i gruppi si riferiscono alle autorizzazioni, non all'autenticazione, e i principali sono entità IAM autenticate.
Ecco alcune caratteristiche importanti dei gruppi di utenti:
- Un **gruppo** di utenti può **contenere molti utenti**, e un **utente** può **appartenere a più gruppi**.
- **I gruppi di utenti non possono essere annidati**; possono contenere solo utenti, non altri gruppi di utenti.
- Non esiste **un gruppo di utenti predefinito che include automaticamente tutti gli utenti nell'account AWS**. Se desideri avere un gruppo di utenti di questo tipo, devi crearlo e assegnare ogni nuovo utente ad esso.
- Il numero e la dimensione delle risorse IAM in un account AWS, come il numero di gruppi e il numero di gruppi di cui un utente può essere membro, sono limitati. Per ulteriori informazioni, vedere [quote IAM e AWS STS](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_iam-quotas.html).
- Il numero e la dimensione delle risorse IAM in un account AWS, come il numero di gruppi e il numero di gruppi di cui un utente può essere membro, sono limitati. Per ulteriori informazioni, vedere [Quote IAM e AWS STS](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_iam-quotas.html).
### [Ruoli IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) <a href="#id_iam-roles" id="id_iam-roles"></a>
@@ -166,10 +166,10 @@ Il Servizio di Token di Sicurezza AWS (STS) è un servizio web che facilita l'**
Vengono utilizzati per assegnare autorizzazioni. Ci sono 2 tipi:
- Politiche gestite da AWS (preconfigurate da AWS)
- Politiche gestite dai clienti: configurate da te. Puoi creare politiche basate su politiche gestite da AWS (modificando una di esse e creando la tua), utilizzando il generatore di politiche (una vista GUI che ti aiuta a concedere e negare autorizzazioni) o scrivendo la tua.
- Politiche gestite dai clienti: configurate da te. Puoi creare politiche basate su politiche gestite da AWS (modificando una di esse e creando la tua), utilizzando il generatore di politiche (una vista GUI che ti aiuta a concedere e negare autorizzazioni) o scrivendo le tue.
Per **default l'accesso** è **negato**, l'accesso sarà concesso se è stato specificato un ruolo esplicito.\
Se **esiste un singolo "Deny", sovrascriverà il "Allow"**, tranne per le richieste che utilizzano le credenziali di sicurezza root dell'account AWS (che sono consentite per impostazione predefinita).
Se **esiste un singolo "Deny", sovrascriverà l'"Allow"**, tranne per le richieste che utilizzano le credenziali di sicurezza root dell'account AWS (che sono consentite per impostazione predefinita).
```javascript
{
"Version": "2012-10-17", //Version of the policy
@@ -197,8 +197,8 @@ I [campi specifici che possono essere utilizzati per condizioni per servizio son
#### Politiche Inline
Questo tipo di politiche sono **assegnate direttamente** a un utente, gruppo o ruolo. Quindi, non appaiono nell'elenco delle Politiche poiché nessun altro può usarle.\
Le politiche inline sono utili se si desidera **mantenere una relazione rigorosa uno a uno tra una politica e l'identità** a cui è applicata. Ad esempio, si vuole essere certi che i permessi in una politica non siano assegnati involontariamente a un'identità diversa da quella per cui sono destinati. Quando si utilizza una politica inline, i permessi nella politica non possono essere attaccati involontariamente all'identità sbagliata. Inoltre, quando si utilizza la Console di gestione AWS per eliminare quell'identità, le politiche incorporate nell'identità vengono eliminate anch'esse. Questo perché fanno parte dell'entità principale.
Questo tipo di politiche sono **assegnate direttamente** a un utente, gruppo o ruolo. Quindi, non appaiono nell'elenco delle Politiche poiché nessun altro può utilizzarle.\
Le politiche inline sono utili se si desidera **mantenere una relazione rigorosa uno a uno tra una politica e l'identità** a cui è applicata. Ad esempio, si vuole essere certi che i permessi in una politica non siano assegnati inavvertitamente a un'identità diversa da quella per cui sono destinati. Quando si utilizza una politica inline, i permessi nella politica non possono essere attaccati inavvertitamente all'identità sbagliata. Inoltre, quando si utilizza la Console di gestione AWS per eliminare quell'identità, le politiche incorporate nell'identità vengono eliminate anch'esse. Questo perché fanno parte dell'entità principale.
#### Politiche dei Bucket di Risorse
@@ -208,9 +208,9 @@ Se un principale non ha un diniego esplicito su di esse, e una politica di risor
### Limiti IAM
I limiti IAM possono essere utilizzati per **limitare i permessi a cui un utente o ruolo dovrebbe avere accesso**. In questo modo, anche se un diverso insieme di permessi viene concesso all'utente da una **politica diversa**, l'operazione **fallirà** se tenta di usarli.
I limiti IAM possono essere utilizzati per **limitare i permessi a cui un utente o un ruolo dovrebbe avere accesso**. In questo modo, anche se un diverso insieme di permessi viene concesso all'utente da una **politica diversa**, l'operazione **fallirà** se tenta di utilizzarli.
Un limite è semplicemente una politica allegata a un utente che **indica il livello massimo di permessi che l'utente o il ruolo può avere**. Quindi, **anche se l'utente ha accesso da Amministratore**, se il limite indica che può solo leggere i bucket S·, questo è il massimo che può fare.
Un limite è semplicemente una politica allegata a un utente che **indica il livello massimo di permessi che l'utente o il ruolo può avere**. Quindi, **anche se l'utente ha accesso da Amministratore**, se il limite indica che può solo leggere i bucket S·, quello è il massimo che può fare.
**Questo**, **SCP** e **seguire il principio del minimo privilegio** sono i modi per controllare che gli utenti non abbiano più permessi di quelli di cui hanno bisogno.
@@ -237,8 +237,6 @@ Un esempio di provider di identità può essere il tuo **Microsoft Active Direct
Per configurare questa fiducia, viene generato un **Provider di Identità IAM (SAML o OAuth)** che **fiducia** la **altra piattaforma**. Poi, almeno un **ruolo IAM è assegnato (fiducioso) al Provider di Identità**. Se un utente della piattaforma fidata accede ad AWS, accederà come il ruolo menzionato.
Tuttavia, di solito vorrai dare un **ruolo diverso a seconda del gruppo dell'utente** nella piattaforma di terze parti. Quindi, diversi **ruoli IAM possono fidarsi** del Provider di Identità di terze parti e la piattaforma di terze parti sarà quella che consentirà agli utenti di assumere un ruolo o l'altro.
<figure><img src="../../../images/image (247).png" alt=""><figcaption></figcaption></figure>
### Centro Identità IAM
@@ -255,7 +253,7 @@ Per accedere agli utenti, ci sono 3 fonti di identità che possono essere utiliz
<figure><img src="../../../images/image (279).png" alt=""><figcaption></figcaption></figure>
Nel caso più semplice della directory del Centro Identità, il **Centro Identità avrà un elenco di utenti e gruppi** e sarà in grado di **assegnare politiche** a loro per **qualsiasi degli account** dell'organizzazione.
Nel caso più semplice della directory del Centro Identità, il **Centro Identità avrà un elenco di utenti e gruppi** e sarà in grado di **assegnare politiche** a loro per **uno qualsiasi degli account** dell'organizzazione.
Per dare accesso a un utente/gruppo del Centro Identità a un account, verrà creato un **Provider di Identità SAML che fida il Centro Identità**, e verrà creato un **ruolo che fida il Provider di Identità con le politiche indicate** nell'account di destinazione.
@@ -288,7 +286,7 @@ L'app utilizza AssumeRoleWithWebIdentity per creare credenziali temporanee. Tutt
### Altre opzioni IAM
- Puoi **impostare un'impostazione della politica delle password** con opzioni come lunghezza minima e requisiti per la password.
- Puoi **impostare un'impostazione della politica delle password** come lunghezza minima e requisiti per la password.
- Puoi **scaricare il "Rapporto Credenziali"** con informazioni sulle credenziali attuali (come il tempo di creazione dell'utente, se la password è abilitata...). Puoi generare un rapporto credenziali fino a una volta ogni **quattro ore**.
AWS Identity and Access Management (IAM) fornisce **controllo degli accessi dettagliato** su tutto AWS. Con IAM, puoi specificare **chi può accedere a quali servizi e risorse**, e sotto quali condizioni. Con le politiche IAM, gestisci i permessi per la tua forza lavoro e i sistemi per **garantire permessi minimi**.
@@ -297,19 +295,21 @@ AWS Identity and Access Management (IAM) fornisce **controllo degli accessi dett
In [**questa pagina**](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_identifiers.html#identifiers-unique-ids) puoi trovare i **prefissi ID IAM** delle chiavi a seconda della loro natura:
| ABIA | [Token bearer del servizio AWS STS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_bearer.html) |
| Codice Identificatore | Descrizione |
| ---- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| ACCA | Credenziale specifica del contesto |
| ABIA | [Token bearer del servizio AWS STS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_bearer.html) |
| ACCA | Credenziale specifica per contesto |
| AGPA | Gruppo utente |
| AIDA | Utente IAM |
| AIPA | Profilo di istanza Amazon EC2 |
| AIPA | Profilo istanza Amazon EC2 |
| AKIA | Chiave di accesso |
| ANPA | Politica gestita |
| ANVA | Versione in una politica gestita |
| APKA | Chiave pubblica |
| AROA | Ruolo |
| ASCA | Certificato |
| ASIA | [ID chiavi di accesso temporanee (AWS STS)](https://docs.aws.amazon.com/STS/latest/APIReference/API_Credentials.html) utilizzano questo prefisso, ma sono uniche solo in combinazione con la chiave di accesso segreta e il token di sessione. |
| ASIA | [ID chiavi di accesso temporanee (AWS STS)](https://docs.aws.amazon.com/STS/latest/APIReference/API_Credentials.html) utilizza questo prefisso, ma è unico solo in combinazione con la chiave di accesso segreta e il token di sessione. |
### Permessi raccomandati per audit degli account
@@ -329,7 +329,7 @@ I seguenti privilegi concedono vari accessi in lettura ai metadati:
### Autenticazione CLI
Affinché un utente normale si autentichi ad AWS tramite CLI, è necessario avere **credenziali locali**. Per impostazione predefinita, puoi configurarle **manualmente** in `~/.aws/credentials` o **eseguendo** `aws configure`.\
In quel file puoi avere più di un profilo, se **nessun profilo** è specificato utilizzando il **aws cli**, verrà utilizzato quello chiamato **`[default]`** in quel file.\
In quel file puoi avere più di un profilo, se **nessun profilo** è specificato utilizzando **aws cli**, verrà utilizzato quello chiamato **`[default]`** in quel file.\
Esempio di file delle credenziali con più di 1 profilo:
```
[default]

View File

@@ -10,7 +10,7 @@ Ogni evento registrato contiene:
- Il nome dell'API chiamata: `eventName`
- Il servizio chiamato: `eventSource`
- Il tempo: `eventTime`
- L'ora: `eventTime`
- L'indirizzo IP: `SourceIPAddress`
- Il metodo dell'agente: `userAgent`. Esempi:
- Signing.amazonaws.com - Dalla Console di gestione AWS
@@ -24,7 +24,7 @@ I log di CloudTrail possono essere **aggregati tra account e tra regioni.**\
CloudTrail consente di utilizzare **l'integrità del file di log per poter verificare che i tuoi file di log siano rimasti invariati** da quando CloudTrail li ha consegnati a te. Crea un hash SHA-256 dei log all'interno di un file di digest. Un hash sha-256 dei nuovi log viene creato ogni ora.\
Quando si crea un Trail, i selettori di eventi ti permetteranno di indicare il trail da registrare: eventi di gestione, dati o approfondimenti.
I log vengono salvati in un bucket S3. Per impostazione predefinita, viene utilizzata la crittografia lato server (SSE-S3), quindi AWS decripterà il contenuto per le persone che hanno accesso, ma per ulteriore sicurezza puoi utilizzare SSE con KMS e le tue chiavi.
I log vengono salvati in un bucket S3. Per impostazione predefinita viene utilizzata la crittografia lato server (SSE-S3), quindi AWS decripterà il contenuto per le persone che hanno accesso, ma per ulteriore sicurezza puoi utilizzare SSE con KMS e le tue chiavi.
I log sono memorizzati in un **bucket S3 con questo formato di nome**:
@@ -88,15 +88,15 @@ La Cronologia Eventi di CloudTrail ti consente di ispezionare in una tabella i l
Le informazioni sono memorizzate nello stesso bucket dei log di CloudTrail in: `BucketName/AWSLogs/AccountID/CloudTrail-Insight`
### Security
| CloudTrail Log File Integrity | <ul><li>Valida se i log sono stati manomessi (modificati o eliminati)</li><li><p>Utilizza file di digest (crea hash per ogni file)</p><ul><li>SHA-256 hashing</li><li>SHA-256 con RSA per la firma digitale</li><li>chiave privata di proprietà di Amazon</li></ul></li><li>Richiede 1 ora per creare un file di digest (eseguito all'ora ogni ora)</li></ul> |
| Control Name | Implementation Details |
| ------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| CloudTrail Log File Integrity | <ul><li>Valida se i log sono stati manomessi (modificati o eliminati)</li><li><p>Utilizza file di digest (crea hash per ogni file)</p><ul><li>SHA-256 hashing</li><li>SHA-256 con RSA per la firma digitale</li><li>chiave privata di proprietà di Amazon</li></ul></li><li>Richiede 1 ora per creare un file di digest (eseguito all'ora ogni ora)</li></ul> |
| Stop unauthorized access | <ul><li><p>Utilizza politiche IAM e politiche del bucket S3</p><ul><li>team di sicurezza —> accesso admin</li><li>auditori —> accesso in sola lettura</li></ul></li><li>Utilizza SSE-S3/SSE-KMS per crittografare i log</li></ul> |
| Prevent log files from being deleted | <ul><li>Restringi l'accesso all'eliminazione con IAM e politiche del bucket</li><li>Configura l'eliminazione MFA di S3</li><li>Valida con la Validazione del File di Log</li></ul> |
## Access Advisor
AWS Access Advisor si basa sugli ultimi 400 giorni di log di AWS **CloudTrail per raccogliere le sue informazioni**. CloudTrail cattura una cronologia delle chiamate API AWS e degli eventi correlati effettuati in un account AWS. Access Advisor utilizza questi dati per **mostrare quando i servizi sono stati accessi l'ultima volta**. Analizzando i log di CloudTrail, Access Advisor può determinare quali servizi AWS un utente IAM o un ruolo ha accesso e quando è avvenuto tale accesso. Questo aiuta gli amministratori AWS a prendere decisioni informate su **come affinare le autorizzazioni**, poiché possono identificare i servizi che non sono stati accessi per lunghi periodi e potenzialmente ridurre autorizzazioni eccessivamente ampie basate su modelli di utilizzo reali.
AWS Access Advisor si basa sugli ultimi 400 giorni di log di AWS **CloudTrail per raccogliere le sue informazioni**. CloudTrail cattura una cronologia delle chiamate API AWS e degli eventi correlati effettuati in un account AWS. Access Advisor utilizza questi dati per **mostrare quando i servizi sono stati ultimi accessi**. Analizzando i log di CloudTrail, Access Advisor può determinare quali servizi AWS un utente IAM o un ruolo ha accesso e quando è avvenuto tale accesso. Questo aiuta gli amministratori AWS a prendere decisioni informate su **come affinare le autorizzazioni**, poiché possono identificare i servizi che non sono stati accessi per lunghi periodi e potenzialmente ridurre autorizzazioni eccessivamente ampie basate su modelli di utilizzo reali.
> [!TIP]
> Pertanto, Access Advisor informa sulle **autorizzazioni non necessarie concesse agli utenti** in modo che l'amministratore possa rimuoverle
@@ -150,7 +150,7 @@ Per ulteriori informazioni su questa specifica tecnica, controlla [https://rhino
I Honeytokens sono creati per **rilevare l'esfiltrazione di informazioni sensibili**. Nel caso di AWS, sono **chiavi AWS il cui utilizzo è monitorato**, se qualcosa attiva un'azione con quella chiave, allora qualcuno deve aver rubato quella chiave.
Tuttavia, i Honeytokens come quelli creati da [**Canarytokens**](https://canarytokens.org/generate)**,** [**SpaceCrab**](https://bitbucket.org/asecurityteam/spacecrab/issues?status=new&status=open)**,** [**SpaceSiren**](https://github.com/spacesiren/spacesiren) utilizzano un nome account riconoscibile o utilizzano lo stesso ID account AWS per tutti i loro clienti. Pertanto, se riesci a ottenere il nome dell'account e/o l'ID dell'account senza far creare alcun log a Cloudtrail, **potresti sapere se la chiave è un honeytoken o meno**.
Tuttavia, i Honeytokens come quelli creati da [**Canarytokens**](https://canarytokens.org/generate)**,** [**SpaceCrab**](https://bitbucket.org/asecurityteam/spacecrab/issues?status=new&status=open)**,** [**SpaceSiren**](https://github.com/spacesiren/spacesiren) utilizzano un nome account riconoscibile o usano lo stesso ID account AWS per tutti i loro clienti. Pertanto, se riesci a ottenere il nome dell'account e/o l'ID dell'account senza far creare alcun log a Cloudtrail, **potresti sapere se la chiave è un honeytoken o meno**.
[**Pacu**](https://github.com/RhinoSecurityLabs/pacu/blob/79cd7d58f7bff5693c6ae73b30a8455df6136cca/pacu/modules/iam__detect_honeytokens/main.py#L57) ha alcune regole per rilevare se una chiave appartiene a [**Canarytokens**](https://canarytokens.org/generate)**,** [**SpaceCrab**](https://bitbucket.org/asecurityteam/spacecrab/issues?status=new&status=open)**,** [**SpaceSiren**](https://github.com/spacesiren/spacesiren)**:**
@@ -185,7 +185,7 @@ Controlla ulteriori informazioni nella [**ricerca originale**](https://medium.co
#### Non generare un log
La tecnica più efficace per questo è in realtà una semplice. Usa semplicemente la chiave che hai appena trovato per accedere a qualche servizio all'interno del tuo account attaccante. Questo farà sì che **CloudTrail generi un log all'interno del TUO account AWS e non all'interno di quello delle vittime**.
La tecnica più efficace per questo è in realtà una semplice. Basta utilizzare la chiave che hai appena trovato per accedere a qualche servizio all'interno del tuo account attaccante. Questo farà sì che **CloudTrail generi un log all'interno del TUO account AWS e non all'interno di quello delle vittime**.
Il fatto è che l'output mostrerà un errore che indica l'ID dell'account e il nome dell'account, quindi **sarai in grado di vedere se si tratta di un Honeytoken**.
@@ -206,7 +206,7 @@ In questo modo, un **attaccante può ottenere l'ARN della chiave senza attivare
Alcuni servizi AWS **genereranno un'infrastruttura** come **Database** o **cluster Kubernetes** (EKS). Un utente **che parla direttamente a quei servizi** (come l'API Kubernetes) **non utilizzerà l'API AWS**, quindi CloudTrail non sarà in grado di vedere questa comunicazione.
Pertanto, un utente con accesso a EKS che ha scoperto l'URL dell'API EKS potrebbe generare un token localmente e **parlare direttamente con il servizio API senza essere rilevato da Cloudtrail**.
Pertanto, un utente con accesso a EKS che ha scoperto l'URL dell'API EKS potrebbe generare un token localmente e **parlare direttamente con il servizio API senza essere rilevato da CloudTrail**.
Ulteriori informazioni in:
@@ -224,7 +224,7 @@ aws cloudtrail delete-trail --name [trail-name]
```bash
aws cloudtrail stop-logging --name [trail-name]
```
#### Disabilita il logging multi-regione
#### Disabilita la registrazione multi-regione
```bash
aws cloudtrail update-trail --name [trail-name] --no-is-multi-region --no-include-global-services
```
@@ -236,7 +236,7 @@ aws cloudtrail put-event-selectors --trail-name <trail_name> --event-selectors '
# Remove all selectors (stop Insights)
aws cloudtrail put-event-selectors --trail-name <trail_name> --event-selectors '[]' --region <region>
```
Nel primo esempio, viene fornito un selettore di eventi singolo come un array JSON con un singolo oggetto. Il `"ReadWriteType": "ReadOnly"` indica che il **selettore di eventi dovrebbe catturare solo eventi di sola lettura** (quindi CloudTrail insights **non controllerà eventi di scrittura** ad esempio).
Nel primo esempio, viene fornito un selettore di eventi singolo come un array JSON con un singolo oggetto. Il `"ReadWriteType": "ReadOnly"` indica che il **selettore di eventi dovrebbe catturare solo eventi di sola lettura** (quindi CloudTrail insights **non controllerà eventi di scrittura**, ad esempio).
Puoi personalizzare il selettore di eventi in base alle tue esigenze specifiche.

View File

@@ -4,7 +4,7 @@
## CloudWatch
**CloudWatch** **raccoglie** dati di monitoraggio e operativi **sotto forma di log/metriche/eventi**, fornendo una **visione unificata delle risorse AWS**, delle applicazioni e dei servizi.\
**CloudWatch** **colleziona** dati di monitoraggio e operativi **sotto forma di log/metriche/eventi**, fornendo una **visione unificata delle risorse AWS**, delle applicazioni e dei servizi.\
CloudWatch Log Event ha una **limitazione di dimensione di 256KB per ogni riga di log**.\
Può impostare **allarmi ad alta risoluzione**, visualizzare **log** e **metriche** affiancati, intraprendere azioni automatiche, risolvere problemi e scoprire informazioni per ottimizzare le applicazioni.
@@ -39,9 +39,9 @@ Le dimensioni sono coppie chiave-valore che fanno parte delle metriche. Aiutano
### Statistiche
Le statistiche sono calcoli matematici eseguiti sui dati delle metriche per riassumerli nel tempo. Le statistiche comuni includono Media, Somma, Minimo, Massimo e Conteggio dei campioni.
Le statistiche sono calcoli matematici eseguiti sui dati delle metriche per riassumerli nel tempo. Le statistiche comuni includono Media, Somma, Minimo, Massimo e ConteggioCampioni.
- **Esempio**: Calcolare la media dell'utilizzo della CPU su un periodo di un'ora.
- **Esempio**: Calcolare l'utilizzo medio della CPU su un periodo di un'ora.
### Unità
@@ -53,37 +53,37 @@ Le unità sono il tipo di misura associato a una metrica. Le unità aiutano a fo
### Dashboard
**Le Dashboard di CloudWatch** forniscono **viste personalizzabili delle metriche di AWS CloudWatch**. È possibile creare e configurare dashboard per visualizzare i dati e monitorare le risorse in un'unica vista, combinando diverse metriche da vari servizi AWS.
**CloudWatch Dashboards** forniscono **viste personalizzabili delle metriche di AWS CloudWatch**. È possibile creare e configurare dashboard per visualizzare i dati e monitorare le risorse in un'unica vista, combinando diverse metriche da vari servizi AWS.
**Caratteristiche principali**:
- **Widget**: Blocchi di costruzione delle dashboard, inclusi grafici, testo, allarmi e altro.
- **Personalizzazione**: Layout e contenuto possono essere personalizzati per soddisfare specifiche esigenze di monitoraggio.
- **Personalizzazione**: Layout e contenuto possono essere personalizzati per soddisfare esigenze di monitoraggio specifiche.
**Esempio di caso d'uso**:
- Una singola dashboard che mostra metriche chiave per l'intero ambiente AWS, incluse le istanze EC2, i database RDS e i bucket S3.
- Un'unica dashboard che mostra metriche chiave per l'intero ambiente AWS, incluse le istanze EC2, i database RDS e i bucket S3.
### Metric Stream e Dati Metrici
**I Metric Streams** in AWS CloudWatch ti consentono di trasmettere continuamente le metriche di CloudWatch a una destinazione a tua scelta in tempo quasi reale. Questo è particolarmente utile per il monitoraggio avanzato, l'analisi e le dashboard personalizzate utilizzando strumenti al di fuori di AWS.
**Metric Streams** in AWS CloudWatch ti consentono di trasmettere continuamente le metriche di CloudWatch a una destinazione a tua scelta in tempo quasi reale. Questo è particolarmente utile per monitoraggio avanzato, analisi e dashboard personalizzati utilizzando strumenti al di fuori di AWS.
**I Dati Metrici** all'interno dei Metric Streams si riferiscono alle misurazioni effettive o ai punti dati che vengono trasmessi. Questi punti dati rappresentano varie metriche come l'utilizzo della CPU, l'uso della memoria, ecc., per le risorse AWS.
**Dati Metrici** all'interno dei Metric Streams si riferiscono alle misurazioni effettive o ai punti dati che vengono trasmessi. Questi punti dati rappresentano varie metriche come l'utilizzo della CPU, l'uso della memoria, ecc., per le risorse AWS.
**Esempio di caso d'uso**:
- Inviare metriche in tempo reale a un servizio di monitoraggio di terze parti per un'analisi avanzata.
- Archiviare metriche in un bucket Amazon S3 per la conservazione a lungo termine e la conformità.
- Inviare metriche in tempo reale a un servizio di monitoraggio di terze parti per analisi avanzate.
- Archiviare metriche in un bucket Amazon S3 per lo stoccaggio a lungo termine e la conformità.
### Allarme
**Gli Allarmi di CloudWatch** monitorano le tue metriche e intraprendono azioni basate su soglie predefinite. Quando una metrica supera una soglia, l'allarme può eseguire una o più azioni come inviare notifiche tramite SNS, attivare una politica di auto-scaling o eseguire una funzione AWS Lambda.
**CloudWatch Alarms** monitorano le tue metriche e intraprendono azioni basate su soglie predefinite. Quando una metrica supera una soglia, l'allarme può eseguire una o più azioni come inviare notifiche tramite SNS, attivare una politica di auto-scaling o eseguire una funzione AWS Lambda.
**Componenti chiave**:
- **Soglia**: Il valore al quale l'allarme si attiva.
- **Periodi di valutazione**: Il numero di periodi su cui i dati vengono valutati.
- **Punti dati per l'allarme**: Il numero di periodi con una soglia raggiunta necessaria per attivare l'allarme.
- **Punti dati per allarme**: Il numero di periodi con una soglia raggiunta necessaria per attivare l'allarme.
- **Azioni**: Cosa succede quando viene attivato uno stato di allarme (ad es., notificare tramite SNS).
**Esempio di caso d'uso**:
@@ -92,7 +92,7 @@ Le unità sono il tipo di misura associato a una metrica. Le unità aiutano a fo
### Rilevatori di anomalie
**I Rilevatori di anomalie** utilizzano l'apprendimento automatico per rilevare automaticamente anomalie nelle tue metriche. Puoi applicare il rilevamento delle anomalie a qualsiasi metrica di CloudWatch per identificare deviazioni dai modelli normali che potrebbero indicare problemi.
**Rilevatori di anomalie** utilizzano l'apprendimento automatico per rilevare automaticamente anomalie nelle tue metriche. Puoi applicare il rilevamento delle anomalie a qualsiasi metrica di CloudWatch per identificare deviazioni dai modelli normali che potrebbero indicare problemi.
**Componenti chiave**:
@@ -101,33 +101,33 @@ Le unità sono il tipo di misura associato a una metrica. Le unità aiutano a fo
**Esempio di caso d'uso**:
- Rilevare modelli di utilizzo della CPU insoliti in un'istanza EC2 che potrebbero indicare una violazione della sicurezza o un problema applicativo.
- Rilevare modelli di utilizzo della CPU insoliti in un'istanza EC2 che potrebbero indicare una violazione della sicurezza o un problema dell'applicazione.
### Regole di Insight e Regole di Insight Gestite
**Le Regole di Insight** ti consentono di identificare tendenze, rilevare picchi o altri modelli di interesse nei tuoi dati metrici utilizzando **espressioni matematiche potenti** per definire le condizioni in base alle quali devono essere intraprese azioni. Queste regole possono aiutarti a identificare anomalie o comportamenti insoliti nelle prestazioni e nell'utilizzo delle tue risorse.
**Regole di Insight** ti consentono di identificare tendenze, rilevare picchi o altri modelli di interesse nei tuoi dati metrici utilizzando **espressioni matematiche potenti** per definire le condizioni sotto le quali devono essere intraprese azioni. Queste regole possono aiutarti a identificare anomalie o comportamenti insoliti nelle prestazioni e nell'utilizzo delle tue risorse.
**Le Regole di Insight Gestite** sono regole di insight **preconfigurate fornite da AWS**. Sono progettate per monitorare servizi AWS specifici o casi d'uso comuni e possono essere attivate senza necessità di configurazione dettagliata.
**Regole di Insight Gestite** sono regole di insight preconfigurate **fornite da AWS**. Sono progettate per monitorare servizi AWS specifici o casi d'uso comuni e possono essere attivate senza necessità di configurazione dettagliata.
**Esempio di caso d'uso**:
- Monitorare le prestazioni di RDS: Abilitare una regola di insight gestita per Amazon RDS che monitora indicatori chiave di prestazione come l'utilizzo della CPU, l'uso della memoria e il disco I/O. Se una di queste metriche supera soglie operative sicure, la regola può attivare un avviso o un'azione di mitigazione automatica.
- Monitoraggio delle prestazioni RDS: Abilitare una regola di insight gestita per Amazon RDS che monitora indicatori chiave di prestazione come l'utilizzo della CPU, l'uso della memoria e il disco I/O. Se una di queste metriche supera soglie operative sicure, la regola può attivare un avviso o un'azione di mitigazione automatica.
### CloudWatch Logs <a href="#cloudwatch-logs" id="cloudwatch-logs"></a>
Consente di **aggregare e monitorare i log delle applicazioni** e dei sistemi dai **servizi AWS** (incluso CloudTrail) e **da app/sistemi** (**CloudWatch Agent** può essere installato su un host). I log possono essere **archiviati indefinitamente** (a seconda delle impostazioni del Log Group) e possono essere esportati.
**Elementi**:
| **Log Group** | Una **collezione di flussi di log** che condividono le stesse impostazioni di retention, monitoraggio e controllo degli accessi |
| Term | Definizione |
| ------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Log Stream** | Una sequenza di **eventi di log** che condividono la **stessa fonte** |
| **Filtri di sottoscrizione** | Definiscono un **modello di filtro che corrisponde agli eventi** in un particolare log group, inviandoli a Kinesis Data Firehose stream, Kinesis stream o a una funzione Lambda |
| **Log Group** | Una **collezione di log stream** che condividono le stesse impostazioni di retention, monitoraggio e controllo degli accessi |
| **Log Stream** | Una sequenza di **eventi di log** che condividono la **stessa fonte** |
| **Subscription Filters** | Definiscono un **modello di filtro che corrisponde agli eventi** in un particolare log group, inviandoli a Kinesis Data Firehose stream, Kinesis stream o a una funzione Lambda |
### Monitoraggio e Eventi di CloudWatch
### CloudWatch Monitoring & Events
CloudWatch **base** aggrega i dati **ogni 5 minuti** (quello **dettagliato** lo fa **ogni 1 minuto**). Dopo l'aggregazione, **controlla le soglie degli allarmi** nel caso debba attivare uno.\
In tal caso, CloudWatch può essere pronto a inviare un evento e intraprendere alcune azioni automatiche (funzioni AWS lambda, argomenti SNS, code SQS, Kinesis Streams)
CloudWatch **base** aggrega i dati **ogni 5 minuti** (quella **dettagliata** lo fa **ogni 1 minuto**). Dopo l'aggregazione, **controlla le soglie degli allarmi** nel caso debba attivarne uno.\
In tal caso, CloudWatch può essere preparato a inviare un evento e intraprendere alcune azioni automatiche (funzioni AWS lambda, argomenti SNS, code SQS, Kinesis Streams)
### Installazione dell'Agente
@@ -135,9 +135,9 @@ Puoi installare agenti all'interno delle tue macchine/contenitori per inviare au
- **Crea** un **ruolo** e **allegalo** all'**istanza** con permessi che consentano a CloudWatch di raccogliere dati dalle istanze oltre a interagire con AWS Systems Manager SSM (CloudWatchAgentAdminPolicy & AmazonEC2RoleforSSM)
- **Scarica** e **installa** l'**agente** sull'istanza EC2 ([https://s3.amazonaws.com/amazoncloudwatch-agent/linux/amd64/latest/AmazonCloudWatchAgent.zip](https://s3.amazonaws.com/amazoncloudwatch-agent/linux/amd64/latest/AmazonCloudWatchAgent.zip)). Puoi scaricarlo dall'interno dell'EC2 o installarlo automaticamente utilizzando AWS Systems Manager selezionando il pacchetto AWS-ConfigureAWSPackage
- **Configura** e **avvia** l'Agente CloudWatch
- **Configura** e **avvia** il CloudWatch Agent
Un log group ha molti flussi. Un flusso ha molti eventi. E all'interno di ciascun flusso, gli eventi sono garantiti in ordine.
Un log group ha molti stream. Uno stream ha molti eventi. E all'interno di ogni stream, gli eventi sono garantiti in ordine.
## Enumerazione
```bash
@@ -216,7 +216,7 @@ aws events list-event-buses
### **`cloudwatch:DeleteAlarms`,`cloudwatch:PutMetricAlarm` , `cloudwatch:PutCompositeAlarm`**
Un attaccante con questi permessi potrebbe compromettere significativamente l'infrastruttura di monitoraggio e allerta di un'organizzazione. Cancellando allarmi esistenti, un attaccante potrebbe disabilitare avvisi cruciali che notificano gli amministratori di problemi critici di prestazioni, violazioni della sicurezza o guasti operativi. Inoltre, creando o modificando allarmi metrici, l'attaccante potrebbe anche fuorviare gli amministratori con falsi avvisi o silenziare allarmi legittimi, mascherando efficacemente attività malevole e impedendo risposte tempestive a incidenti reali.
Un attaccante con questi permessi potrebbe compromettere significativamente l'infrastruttura di monitoraggio e allerta di un'organizzazione. Cancellando allarmi esistenti, un attaccante potrebbe disabilitare avvisi cruciali che notificano gli amministratori di problemi di prestazioni critici, violazioni della sicurezza o guasti operativi. Inoltre, creando o modificando allarmi metrici, l'attaccante potrebbe anche fuorviare gli amministratori con avvisi falsi o silenziare allarmi legittimi, mascherando efficacemente attività malevole e impedendo risposte tempestive a incidenti reali.
Inoltre, con il permesso **`cloudwatch:PutCompositeAlarm`**, un attaccante sarebbe in grado di creare un ciclo di allarmi compositi, dove l'allarme composito A dipende dall'allarme composito B, e l'allarme composito B dipende anche dall'allarme composito A. In questo scenario, non è possibile eliminare alcun allarme composito che fa parte del ciclo perché c'è sempre un allarme composito che dipende da quell'allarme che si desidera eliminare.
```bash
@@ -227,7 +227,7 @@ aws cloudwatch put-composite-alarm --alarm-name <value> --alarm-rule <value> [--
L'esempio seguente mostra come rendere inefficace un allarme metrico:
- Questo allarme metrico monitora l'utilizzo medio della CPU di una specifica istanza EC2, valuta la metrica ogni 300 secondi e richiede 6 periodi di valutazione (30 minuti in totale). Se l'utilizzo medio della CPU supera il 60% per almeno 4 di questi periodi, l'allarme si attiverà e invierà una notifica al topic SNS specificato.
- Modificando la soglia a più del 99%, impostando il periodo a 10 secondi, i periodi di valutazione a 8640 (poiché 8640 periodi di 10 secondi equivalgono a 1 giorno) e i punti dati per l'allarme a 8640, sarebbe necessario che l'utilizzo della CPU fosse superiore al 99% ogni 10 secondi per l'intero periodo di 24 ore per attivare un allarme.
- Modificando la soglia per essere superiore al 99%, impostando il periodo a 10 secondi, i periodi di valutazione a 8640 (poiché 8640 periodi di 10 secondi equivalgono a 1 giorno) e i punti dati per l'allarme a 8640, sarebbe necessario che l'utilizzo della CPU fosse superiore al 99% ogni 10 secondi per l'intero periodo di 24 ore per attivare un allarme.
{{#tabs }}
{{#tab name="Original Metric Alarm" }}
@@ -285,7 +285,7 @@ L'esempio seguente mostra come rendere inefficace un allarme metrico:
Eliminando le azioni di allerta, l'attaccante potrebbe impedire che vengano attivati avvisi critici e risposte automatiche quando viene raggiunto uno stato di allerta, come notificare gli amministratori o attivare attività di auto-scaling. Abilitare o riabilitare in modo inappropriato le azioni di allerta potrebbe anche portare a comportamenti imprevisti, sia riattivando azioni precedentemente disabilitate sia modificando quali azioni vengono attivate, causando potenzialmente confusione e deviazione nella risposta agli incidenti.
Inoltre, un attaccante con il permesso potrebbe manipolare gli stati di allerta, essendo in grado di creare falsi allarmi per distrarre e confondere gli amministratori, o silenziare allarmi genuini per nascondere attività malevole in corso o gravi guasti di sistema.
Inoltre, un attaccante con il permesso potrebbe manipolare gli stati di allerta, essendo in grado di creare falsi allarmi per distrarre e confondere gli amministratori, o silenziare allarmi genuini per nascondere attività malevole in corso o guasti critici del sistema.
- Se utilizzi **`SetAlarmState`** su un allarme composito, l'allarme composito non è garantito a tornare al suo stato effettivo. Torna al suo stato effettivo solo una volta che uno dei suoi allarmi figli cambia stato. Viene anche rivalutato se aggiorni la sua configurazione.
```bash
@@ -302,7 +302,7 @@ Un attaccante sarebbe in grado di compromettere la capacità di rilevare e rispo
aws cloudwatch delete-anomaly-detector [--cli-input-json <value> | --namespace <value> --metric-name <value> --dimensions <value> --stat <value>]
aws cloudwatch put-anomaly-detector [--cli-input-json <value> | --namespace <value> --metric-name <value> --dimensions <value> --stat <value> --configuration <value> --metric-characteristics <value>]
```
L'esempio seguente mostra come rendere inefficace un rilevatore di anomalie metriche. Questo rilevatore di anomalie metriche monitora l'utilizzo medio della CPU di un'istanza EC2 specifica, e basta aggiungere il parametro “ExcludedTimeRanges” con l'intervallo di tempo desiderato, per garantire che il rilevatore di anomalie non analizzi né avvisi su dati rilevanti durante quel periodo.
L'esempio seguente mostra come rendere inefficace un rilevatore di anomalie metriche. Questo rilevatore di anomalie metriche monitora l'utilizzo medio della CPU di un'istanza EC2 specifica, e basta aggiungere il parametro “ExcludedTimeRanges” con l'intervallo di tempo desiderato per garantire che il rilevatore di anomalie non analizzi né avvisi su dati rilevanti durante quel periodo.
{{#tabs }}
{{#tab name="Original Metric Anomaly Detector" }}
@@ -323,7 +323,7 @@ L'esempio seguente mostra come rendere inefficace un rilevatore di anomalie metr
```
{{#endtab }}
{{#tab name="Rilevatore di Anomalie con Metriche Modificate" }}
{{#tab name="Modified Metric Anomaly Detector" }}
```json
{
"SingleMetricAnomalyDetector": {
@@ -364,7 +364,7 @@ aws cloudwatch put-dashboard --dashboard-name <value> --dashboard-body <value>
### **`cloudwatch:DeleteInsightRules`, `cloudwatch:PutInsightRule`, `cloudwatch:PutManagedInsightRule`**
Le regole di insight vengono utilizzate per rilevare anomalie, ottimizzare le prestazioni e gestire le risorse in modo efficace. Cancellando le regole di insight esistenti, un attaccante potrebbe rimuovere capacità di monitoraggio critiche, lasciando il sistema cieco a problemi di prestazioni e minacce alla sicurezza. Inoltre, un attaccante potrebbe creare o modificare regole di insight per generare dati fuorvianti o nascondere attività dannose, portando a diagnosi errate e risposte inappropriate da parte del team operativo.
Le regole di insight vengono utilizzate per rilevare anomalie, ottimizzare le prestazioni e gestire le risorse in modo efficace. Eliminando le regole di insight esistenti, un attaccante potrebbe rimuovere capacità di monitoraggio critiche, lasciando il sistema cieco a problemi di prestazioni e minacce alla sicurezza. Inoltre, un attaccante potrebbe creare o modificare regole di insight per generare dati fuorvianti o nascondere attività dannose, portando a diagnosi errate e risposte inappropriate da parte del team operativo.
```bash
aws cloudwatch delete-insight-rules --rule-names <value>
aws cloudwatch put-insight-rule --rule-name <value> --rule-definition <value> [--rule-state <value>]
@@ -374,7 +374,7 @@ aws cloudwatch put-managed-insight-rules --managed-rules <value>
### **`cloudwatch:DisableInsightRules`, `cloudwatch:EnableInsightRules`**
Disabilitando regole di insight critiche, un attaccante potrebbe effettivamente rendere cieca l'organizzazione rispetto a metriche chiave di prestazioni e sicurezza. Al contrario, abilitando o configurando regole fuorvianti, potrebbe essere possibile generare dati falsi, creare rumore o nascondere attività malevole.
Disabilitando regole di insight critiche, un attaccante potrebbe effettivamente accecare l'organizzazione rispetto a metriche chiave di prestazioni e sicurezza. Al contrario, abilitando o configurando regole fuorvianti, potrebbe essere possibile generare dati falsi, creare rumore o nascondere attività malevole.
```bash
aws cloudwatch disable-insight-rules --rule-names <value>
aws cloudwatch enable-insight-rules --rule-names <value>
@@ -383,11 +383,11 @@ aws cloudwatch enable-insight-rules --rule-names <value>
### **`cloudwatch:DeleteMetricStream` , `cloudwatch:PutMetricStream` , `cloudwatch:PutMetricData`**
Un attaccante con i permessi **`cloudwatch:DeleteMetricStream`** , **`cloudwatch:PutMetricStream`** sarebbe in grado di creare e eliminare flussi di dati metrici, compromettendo la sicurezza, il monitoraggio e l'integrità dei dati:
Un attaccante con i permessi **`cloudwatch:DeleteMetricStream`** , **`cloudwatch:PutMetricStream`** sarebbe in grado di creare e cancellare flussi di dati metrici, compromettendo la sicurezza, il monitoraggio e l'integrità dei dati:
- **Creare flussi malevoli**: Creare flussi metrici per inviare dati sensibili a destinazioni non autorizzate.
- **Manipolazione delle risorse**: La creazione di nuovi flussi metrici con dati eccessivi potrebbe produrre molto rumore, causando allarmi errati, mascherando problemi reali.
- **Interruzione del monitoraggio**: Eliminando i flussi metrici, gli attaccanti interromperebbero il flusso continuo di dati di monitoraggio. In questo modo, le loro attività malevole sarebbero efficacemente nascoste.
- **Manipolazione delle risorse**: La creazione di nuovi flussi metrici con dati eccessivi potrebbe produrre molto rumore, causando allarmi errati e mascherando problemi reali.
- **Interruzione del monitoraggio**: Cancellando i flussi metrici, gli attaccanti interromperebbero il flusso continuo di dati di monitoraggio. In questo modo, le loro attività malevole sarebbero efficacemente nascoste.
Allo stesso modo, con il permesso **`cloudwatch:PutMetricData`**, sarebbe possibile aggiungere dati a un flusso metrico. Questo potrebbe portare a un DoS a causa della quantità di dati impropri aggiunti, rendendolo completamente inutile.
```bash