Introduzione a autorizzazioni, accesso e gruppi di sicurezza

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019 | TFS 2018

Quando si tratta di accedere a una funzionalità di Azure DevOps, è utile comprendere i concetti chiave seguenti.

  • Informazioni sulle autorizzazioni:

    • Tutti gli utenti aggiunti ad Azure DevOps vengono aggiunti a uno o più gruppi di sicurezza predefiniti.
    • Ai gruppi di sicurezza vengono assegnate autorizzazioni che consentono o negano l'accesso a una funzionalità o a un'attività.
    • I membri di un gruppo di sicurezza ereditano le autorizzazioni assegnate al gruppo.
    • Le autorizzazioni sono definite a livelli diversi: organizzazione/raccolta, progetto o oggetto.
    • Altre autorizzazioni vengono gestite tramite assegnazioni basate sui ruoli, ad esempio l'amministratore del team, la gestione delle estensioni e vari ruoli delle risorse della pipeline.
    • Gli amministratori possono definire gruppi di sicurezza personalizzati per gestire le autorizzazioni per aree funzionali diverse.
  • Informazioni sui livelli di accesso:

    • Tutti gli utenti aggiunti ad Azure DevOps vengono assegnati a un livello di accesso, che concede o limita l'accesso per selezionare le funzionalità del portale Web.
    • Esistono tre livelli di accesso principali: Stakeholder, Basic e Basic + Test Plans.
    • L'accesso degli stakeholder consente l'accesso gratuito a un numero illimitato di utenti a un set limitato di funzionalità. Per informazioni dettagliate, vedere Informazioni di riferimento rapido sull'accesso agli stakeholder.
  • Informazioni sulle funzionalità di anteprima:
    • Man mano che vengono introdotte nuove funzionalità, gli utenti possono abilitarli o disabilitarli tramite le funzionalità di anteprima per accedervi.
    • Un piccolo subset di nuove funzionalità viene gestito a livello di organizzazione e abilitato o disabilitato dai proprietari dell'organizzazione.

Ad esempio, la maggior parte degli utenti di Azure DevOps viene aggiunta al gruppo di sicurezza Collaboratori e ha concesso il livello di accesso Basic . Il gruppo Collaboratori fornisce l'accesso in lettura e scrittura ai repository, al rilevamento del lavoro, alle pipeline e altro ancora. L'accesso di base consente l'accesso a tutte le funzionalità e le attività per l'uso di Azure Boards, Azure Repos, Azure Pipelines e Azure Artifacts. Agli utenti che richiedono l'accesso per gestire Azure Test Plans è necessario concedere l'accesso Basic + Test Plans o Avanzato.

Gli amministratori devono essere aggiunti al gruppo Amministratori raccolta di progetti o Amministratori progetto. Gli amministratori gestiscono gruppi di sicurezza e autorizzazioni dal portale Web, principalmente dalle impostazioni di Project. I collaboratori gestiscono anche le autorizzazioni per gli oggetti creati dal portale Web.

Per una panoramica delle autorizzazioni predefinite, vedere Informazioni di riferimento rapido sulle autorizzazioni predefinite.

Gruppi di sicurezza e appartenenza

Con la creazione di un'organizzazione, una raccolta o un progetto, Azure DevOps crea un set di gruppi di sicurezza predefiniti, a cui vengono assegnate automaticamente le autorizzazioni predefinite. I gruppi di sicurezza aggiuntivi sono definiti con le azioni seguenti:

  • Quando si creano gruppi di sicurezza personalizzati ai livelli seguenti:
    • A livello di progetto
    • Organizzazione o livello di raccolta
    • A livello di server (solo locale)
  • Quando si aggiunge un team, viene creato un gruppo di sicurezza del team

Suggerimento

Non è possibile creare un gruppo di sicurezza a livello di oggetto, ma è possibile assegnare un gruppo personalizzato a un livello di oggetto e assegnare autorizzazioni a tale livello. Per altre informazioni sulle autorizzazioni a livello di oggetto, vedere Impostare le autorizzazioni a livello di oggetto.

Gruppi di sicurezza predefiniti

I gruppi di sicurezza seguenti sono definiti per impostazione predefinita per ogni progetto e organizzazione. In genere si aggiungono utenti o gruppi ai gruppi Reader, Contributors o Project Administrators .

Project Organizzazione o raccolta
- Amministratori di compilazione
-Contributori
- Amministratori progetto
- Utenti validi del progetto
-Lettori
- Release Administrators
- TeamName Team
- Amministratori raccolta progetti
- Amministratori di compilazione raccolta progetti
- Account del servizio di compilazione raccolta progetti
- Account del servizio proxy di raccolta progetti
- Account del servizio raccolta progetti
- Account del servizio di test della raccolta di progetti
- Utenti validi per la raccolta di progetti
- utenti Project-Scoped
- Gruppo di servizi di sicurezza

Per una descrizione di ognuno di questi gruppi, vedere Gruppi di sicurezza, account di servizio e autorizzazioni. Per le assegnazioni di autorizzazioni predefinite effettuate ai gruppi di sicurezza predefiniti più comuni, vedere Autorizzazioni e accesso predefiniti.

I gruppi di sicurezza seguenti sono definiti per impostazione predefinita per ogni progetto e raccolta di progetti. In genere si aggiungono utenti o gruppi ai gruppi Reader, Contributors o Project Administrators .

Nota

L'elenco seguente indica i gruppi più recenti definiti per TFS 2017 e versioni successive. Per le versioni precedenti di Azure DevOps, l'elenco può differire. Aggiungere solo account di servizio ai gruppi di account del servizio Azure DevOps. Per informazioni sui gruppi di utenti validi, vedere Gruppi di utenti validi più avanti in questo articolo.

Livello di progetto Livello di raccolta
- Amministratori di compilazione
-Contributori
- Amministratori progetto
- Utenti validi del progetto
-Lettori
- Release Administrators
- TeamName Team
- Amministratori raccolta progetti
- Amministratori di compilazione raccolta progetti
- Account del servizio di compilazione raccolta progetti
- Account del servizio proxy di raccolta progetti
- Account del servizio raccolta progetti
- Account del servizio di test della raccolta di progetti
- Utenti validi per la raccolta di progetti
- Gruppo di servizi di sicurezza

Suggerimento

Per gli utenti con attività di gestione delle funzionalità a livello di progetto, ad esempio team, aree e percorsi di iterazione, repository, hook del servizio e endpoint del servizio, aggiungerli al gruppo Amministratori progetto. Per gli utenti con attività di gestione delle funzionalità a livello di organizzazione o raccolta, ad esempio progetti, criteri, processi, criteri di conservazione, pool di distribuzione e agenti, e estensioni, aggiungerle al gruppo Amministratori raccolta progetti. Per altre informazioni, vedere Informazioni su utente, team, progetto e impostazioni a livello di organizzazione.

Per una descrizione di ogni gruppo e di ogni autorizzazione, vedere Informazioni di riferimento su autorizzazioni e gruppi, Gruppi.

Gestione a livello di appartenenza, autorizzazione e accesso

Azure DevOps controlla l'accesso tramite queste tre aree funzionali connesse:

  • Gestione delle appartenenze supporta l'aggiunta di singoli account utente e di gruppi a gruppi di sicurezza predefiniti. Ogni gruppo predefinito viene associato a un set di autorizzazioni predefinite. Tutti gli utenti aggiunti a qualsiasi gruppo di sicurezza vengono aggiunti al gruppo Utenti validi. Un utente valido è un utente che può connettersi a un progetto, a una raccolta o a un'organizzazione.

  • Gestione delle autorizzazioni controlla l'accesso a specifiche attività funzionali a diversi livelli del sistema. Le autorizzazioni a livello di oggetto impostano le autorizzazioni per un file, una cartella, una pipeline di compilazione o una query condivisa. Le impostazioni delle autorizzazioni corrispondono a Consenti, Nega, Consenti ereditato, Rifiuta ereditato e Non impostato. Per altre informazioni sull'ereditarietà, vedere Ereditarietà delle autorizzazioni e gruppi di sicurezza più avanti in questo articolo.

  • La gestione a livello di accesso controlla l'accesso alle funzionalità del portale Web. In base a ciò che è stato acquistato per un utente, gli amministratori impostano il livello di accesso dell'utente su Stakeholder, Basic, Basic + Test o Visual Studio Enterprise (in precedenza Avanzate).

Ogni area funzionale usa i gruppi di sicurezza per semplificare la gestione all'interno della distribuzione. Gli utenti e i gruppi vengono aggiunti tramite il contesto di amministrazione Web. Le autorizzazioni vengono impostate automaticamente in base sul gruppo di sicurezza a cui sono stati aggiunti gli utenti o in base al livello di oggetto, progetto, raccolta o server a cui sono stati aggiunti i gruppi.

I membri dei gruppi di sicurezza possono essere costituiti da una combinazione di utenti, altri gruppi e gruppi di Azure Active Directory.

I membri del gruppo di sicurezza possono essere una combinazione di utenti, altri gruppi e gruppi di Active Directory o un gruppo di lavoro.

È possibile creare gruppi locali o gruppi di Active Directory (AD) per gestire gli utenti.

Gruppi di sicurezza di Active Directory e Azure Active Directory

È possibile popolare i gruppi di sicurezza aggiungendo singoli utenti. Tuttavia, per semplificare la gestione, è più semplice se si popolano questi gruppi usando Azure Active Directory (Azure AD) per Azure DevOps Services e Active Directory (AD) o gruppi di utenti Windows per Azure DevOps Server. Questo metodo consente di gestire l'appartenenza ai gruppi e le autorizzazioni in modo più efficiente in più computer.

Se è necessario gestire solo un piccolo set di utenti, è possibile ignorare questo passaggio. Tuttavia, se si prevede che l'organizzazione possa crescere, è possibile configurare AD o Azure AD. Inoltre, se si prevede di pagare per servizi aggiuntivi, è necessario configurare Azure AD per l'uso con Azure DevOps per supportare la fatturazione.

Nota

Senza Azure AD, tutti gli utenti di Azure DevOps devono accedere usando gli account Microsoft e è necessario gestire l'accesso dell'account da singoli account utente. Anche se si gestisce l'accesso all'account tramite account Microsoft, è necessario configurare una sottoscrizione di Azure per gestire la fatturazione.

Per configurare Azure Active Directory da usare con Azure DevOps Services, vedere Connettere l'organizzazione ad Azure Active Directory.

Nota

Quando l'organizzazione è connessa ad Azure Active Directory, esistono diversi criteri dell'organizzazione che è possibile abilitare o disabilitare per proteggere l'organizzazione. Per altre informazioni, vedere Informazioni sulla sicurezza, l'autenticazione e l'autorizzazione, i criteri di sicurezza.

Per gestire l'accesso dell'organizzazione con Azure AD, vedere gli articoli seguenti:

Azure DevOps registra le modifiche apportate a un gruppo di Azure AD entro un'ora dalla modifica in Azure AD e aggiorna le autorizzazioni ereditate tramite l'appartenenza a tale gruppo. Inoltre, qualsiasi utente di Azure DevOps può attivare un aggiornamento dell'appartenenza ad Azure AD, insieme alle autorizzazioni ereditate in Azure DevOps disconnettendosi e eseguendo nuovamente l'accesso o attivando un aggiornamento per valutare nuovamente l'autorizzazione.

Per configurare Active Directory per l'uso con Azure DevOps Server, vedere gli articoli seguenti:

In genere, è necessario installare Active Directory prima di installare Azure DevOps Server.

Gruppi di utenti validi

Quando si aggiungono account di utenti direttamente a un gruppo di sicurezza, vengono aggiunti automaticamente a uno dei gruppi di utenti validi.

  • Utenti validi della raccolta di progetti: tutti i membri aggiunti a un gruppo a livello di organizzazione.
  • Utenti validi del progetto: tutti i membri aggiunti a un gruppo a livello di progetto.
  • Server\Azure DevOps Validi Utenti: tutti i membri aggiunti ai gruppi a livello di server.
  • ProjectCollectionName\Project Collection Valid Users: tutti i membri aggiunti ai gruppi a livello di raccolta.
  • ProjectName\Project Valid Users: tutti i membri aggiunti ai gruppi a livello di progetto.
  • Utenti validi di Server\Team Foundation: tutti i membri aggiunti ai gruppi a livello di server.
  • ProjectCollectionName\Project Collection Valid Users: tutti i membri aggiunti ai gruppi a livello di raccolta.
  • ProjectName\Project Valid Users: tutti i membri aggiunti ai gruppi a livello di progetto.

Le autorizzazioni predefinite assegnate a questi gruppi sono principalmente limitate all'accesso in lettura, ad esempio Visualizza risorse di compilazione, Visualizza informazioni a livello di progetto e Visualizza informazioni a livello di raccolta.

Ciò significa che tutti gli utenti aggiunti a un progetto possono visualizzare gli oggetti in altri progetti all'interno di una raccolta. Se è necessario limitare l'accesso alla visualizzazione, è possibile impostare restrizioni tramite il nodo percorso dell'area.

Se si rimuove o nega l'autorizzazione Visualizza informazioni a livello di istanza per uno dei gruppi di utenti validi, nessun membro del gruppo è in grado di accedere al progetto, alla raccolta o alla distribuzione, a seconda del gruppo impostato.

Gruppo di utenti con ambito progetto

Per impostazione predefinita, gli utenti aggiunti a un'organizzazione possono visualizzare tutte le informazioni e le impostazioni del progetto. Ciò include la visualizzazione dell'elenco degli utenti, l'elenco di progetti, i dettagli di fatturazione, i dati di utilizzo e altro ancora a cui si accede tramite Impostazioni organizzazione.

Per limitare gli utenti selezionati, ad esempio stakeholder, utenti guest di Azure Active Directory o membri di un gruppo di sicurezza specifico, è possibile abilitare la funzionalità Limita visibilità utente e collaborazione a progetti specifici per l'organizzazione. Dopo aver abilitato, qualsiasi utente o gruppo aggiunto al gruppo Utenti con ambito progetto , è limitato dall'accesso alle pagine Impostazioni organizzazione , ad eccezione di Panoramica e progetti; e sono limitati all'accesso solo ai progetti a cui sono stati aggiunti.

Per abilitare questa funzionalità, vedere Gestire o abilitare le funzionalità.

Nota

Tutti i gruppi di sicurezza sono entità a livello di organizzazione, anche quelli che dispongono solo delle autorizzazioni per un progetto specifico. Dal portale Web, la visibilità di alcuni gruppi di sicurezza può essere limitata in base alle autorizzazioni utente. È tuttavia possibile individuare i nomi di tutti i gruppi di un'organizzazione usando lo strumento dell'interfaccia della riga di comando di Azure devops o le API REST. Per altre informazioni, vedere Aggiungere e gestire i gruppi di sicurezza.

Nota

Tutti i gruppi di sicurezza sono entità a livello di raccolta, anche quelli che dispongono solo delle autorizzazioni per un progetto specifico. Dal portale Web, la visibilità di alcuni gruppi di sicurezza può essere limitata in base alle autorizzazioni utente. È tuttavia possibile individuare i nomi di tutti i gruppi di un'organizzazione usando lo strumento dell'interfaccia della riga di comando di Azure devops o le API REST. Per altre informazioni, vedere Aggiungere e gestire i gruppi di sicurezza.

Nota

Tutti i gruppi di sicurezza sono entità a livello di raccolta, anche quelli che dispongono solo delle autorizzazioni per un progetto specifico. Dal portale Web, la visibilità di alcuni gruppi di sicurezza può essere limitata in base alle autorizzazioni utente. È tuttavia possibile individuare i nomi di tutti i gruppi di un'organizzazione usando le API REST. Per altre informazioni, vedere Aggiungere e gestire i gruppi di sicurezza.

Livelli di accesso

I livelli di accesso controllano le funzionalità visibili agli utenti nel portale Web e dipendono dalle licenze utente; le autorizzazioni controllano la possibilità di connettersi ad Azure DevOps e usare le funzionalità in Azure DevOps. Se si sta tentando di concedere a un utente l'accesso alle funzionalità di gestione del portfolio Agile o di gestione dei test case, si vuole modificare i livelli di accesso, non le autorizzazioni.

L'impostazione del livello di accesso per utenti o gruppi non fornisce loro l'accesso a un progetto o al portale Web. Solo gli utenti o i gruppi aggiunti a un team o a un gruppo di sicurezza possono connettersi a un progetto e al portale Web. Assicurarsi che gli utenti dispongano delle autorizzazioni e del livello di accesso necessari. A tale scopo, assicurarsi che vengano aggiunti al progetto o a un team.

Autorizzazioni

Come illustrato nell'immagine seguente, i gruppi di sicurezza definiti a livello di progetto e raccolta possono essere assegnati alle autorizzazioni assegnate all'oggetto, al progetto e a livello di organizzazione.

Mapping concettuale dei gruppi di sicurezza predefiniti ai livelli di autorizzazione, cloud

Come illustrato nell'immagine seguente, i gruppi di sicurezza definiti a livello di progetto e raccolta possono essere assegnati alle autorizzazioni assegnate a livello di oggetto, progetto e raccolta. È possibile definire solo gruppi di sicurezza a livello di server per le autorizzazioni a livello di server.

Mapping concettuale dei gruppi di sicurezza predefiniti ai livelli di autorizzazione, in locale

Immagine concettuale dei gruppi di sicurezza e dei livelli di autorizzazione, TFS-2018 e versioni precedenti

Per una descrizione di ogni gruppo di sicurezza predefinito, vedere Gruppi di sicurezza, account di servizio e autorizzazioni.

Stati di autorizzazione

Esistono cinque possibili assegnazioni effettuate a un'autorizzazione. Concede o limita l'accesso come indicato.

  • L'utente o il gruppo dispone delle autorizzazioni per eseguire un'attività:
    • Consentito
    • Consenti ereditato
  • L'utente o il gruppo non dispone dell'autorizzazione per eseguire un'attività:
    • Nega
    • Rifiuta ereditato
    • Non impostato

Ecco cosa è necessario conoscere le impostazioni di autorizzazione:

  • Consenti o Nega concede esplicitamente o limita gli utenti a eseguire attività specifiche e in genere vengono ereditati dall'appartenenza al gruppo.

  • Non impostato in modo implicito nega agli utenti la possibilità di eseguire attività che richiedono tale autorizzazione, ma consente l'appartenenza a un gruppo che dispone di tale autorizzazione impostata per avere la precedenza, nota anche come Allow ( ereditato) o Ereditato consenti e Nega (ereditato) o Rifiuto ereditato.

  • Per la maggior parte dei gruppi e quasi tutte le autorizzazioni, Nega override Consenti. Se un utente appartiene a due gruppi e uno di essi dispone di un'autorizzazione specifica impostata su Deny, tale utente non è in grado di eseguire attività che richiedono l'autorizzazione anche se appartengono a un gruppo con tale autorizzazione impostata su Consenti.

    In alcuni casi, i membri dei gruppi Amministratori raccolta progetto o Amministratori di Team Foundation possono sempre ottenere l'autorizzazione anche se vengono negate tale autorizzazione in un gruppo diverso. In altri casi, ad esempio l'eliminazione o la pipeline dell'elemento di lavoro, essere membro degli amministratori della raccolta di progetti non ignora le autorizzazioni Nega impostate altrove.

  • La modifica di un'autorizzazione per un gruppo modifica l'autorizzazione per tutti gli utenti membri di tale gruppo. In altre parole, a seconda della dimensione del gruppo, è possibile influire sulla capacità di centinaia di utenti di eseguire i processi modificando semplicemente un'autorizzazione. Pertanto assicurarsi di conoscerne l'impatto prima di apportare una modifica.

Ereditarietà delle autorizzazioni e gruppi di sicurezza

Alcune autorizzazioni vengono gestite tramite una gerarchia. All'interno di questa gerarchia, le autorizzazioni possono essere ereditate dall'elemento padre o sottoposto a override. I gruppi di sicurezza assegnano un set di autorizzazioni a tali membri del gruppo. Ad esempio, ai membri del gruppo Collaboratori o del gruppo Amministratori progetto vengono assegnate le autorizzazioni impostate su Consentito per tali gruppi.

Se un'autorizzazione non è consentita o negata direttamente per un utente, può essere ereditata in due modi.

  • Gli utenti ereditano le autorizzazioni dai gruppi a cui appartengono. Quando un'autorizzazione è consentita per un utente direttamente o tramite l'appartenenza a un gruppo che dispone di tale autorizzazione e viene negata, direttamente o tramite l'appartenenza al gruppo, l'autorizzazione viene negata.

    I membri degli amministratori della raccolta di progetti o degli amministratori di Team Foundation mantengono la maggior parte delle autorizzazioni consentite, anche se appartengono ad altri gruppi che negano tali autorizzazioni. Le autorizzazioni per l'operazione degli elementi di lavoro sono l'eccezione a questa regola.

  • Le autorizzazioni a livello di oggetto assegnate per i nodi di una gerarchia, ovvero aree, iterazioni, cartelle di controllo della versione, cartelle di query degli elementi di lavoro, vengono ereditate nella gerarchia. Ovvero, le autorizzazioni di un utente impostate in area-1 vengono ereditate da area-1/sub-area-1, se la stessa autorizzazione non è consentita o negata in modo esplicito per area-1/sub-area-1. Se un'autorizzazione viene impostata in modo esplicito per un oggetto, ad esempio area-1/sub-area-1, il nodo padre non viene ereditato, indipendentemente dal fatto che venga negato o consentito. Se non è impostato, le autorizzazioni per tale nodo vengono ereditate dal predecessore più vicino con l'autorizzazione impostata in modo esplicito. Infine, nella gerarchia degli oggetti, la specificità prevale sull'ereditarietà. Ad esempio, un utente le cui autorizzazioni sono impostate in modo esplicito su Nega in "area-1", ma sono anche impostate in modo esplicito su Consenti per "area-1/area secondaria-1" riceverà infine un consenti in 'area-1/area secondaria-1'.

Per comprendere perché viene ereditata un'autorizzazione, è possibile sospendere un'impostazione di autorizzazione e quindi scegliere Perché? Per aprire una pagina Sicurezza , vedere Visualizzare le autorizzazioni.

Nota

Per abilitare la pagina anteprima delle impostazioni delle autorizzazioni del progetto , vedere Abilitare le funzionalità di anteprima.

Finestra di dialogo Autorizzazioni, pagina di anteprima, Motivo dell'annotazione del collegamento.

Verrà visualizzata una nuova finestra di dialogo che mostra le informazioni sull'ereditarietà per tale autorizzazione.

L'interfaccia utente di anteprima per la pagina Impostazioni autorizzazioni progetto non è disponibile per Azure DevOps Server 2020 e versioni precedenti.

Quando si assegnano autorizzazioni

Che cosa fare:

  • Usare Azure Active Directory, Active Directory o gruppi di sicurezza di Windows quando si gestiscono molti utenti.
  • Durante l'aggiunta di team, considerare le autorizzazioni da assegnare a responsabili del team, scrum master e altri membri del team che possono avere la necessità di creare e modificare percorsi area, percorsi e iterazione e query.
  • Quando si aggiungono molti team, è consigliabile creare un gruppo personalizzato Amministratori team in cui si alloca un subset delle autorizzazioni disponibili per gli amministratori di Project.
  • Valutare la possibilità di concedere alle cartelle di query dell'elemento di lavoro l'autorizzazione Contribuire a utenti o gruppi che richiedono la possibilità di creare e condividere query sugli elementi di lavoro per il progetto.

Che cosa non fare:

  • Non aggiungere utenti a più gruppi di sicurezza che contengono livelli di autorizzazione diversi. In alcuni casi, un livello di autorizzazione Nega può eseguire l'override di un livello di autorizzazione Consenti .
  • Non modificare le assegnazioni predefinite effettuate ai gruppi di utenti validi. Se si rimuove o si imposta l'autorizzazione Visualizza informazioni a livello di istanza su Nega per uno dei gruppi Utenti validi, nessun utente del gruppo può accedere al progetto, alla raccolta o alla distribuzione, a seconda del gruppo impostato.
  • Non assegnare autorizzazioni indicate come "Assegna solo agli account del servizio" agli account utente.

Autorizzazioni basate sui ruoli

Con le autorizzazioni basate sui ruoli, si assegnano account utente o gruppi di sicurezza a un ruolo, con ogni ruolo a cui è stata assegnata una o più autorizzazioni. Ecco i ruoli principali e i collegamenti per altre informazioni.

Funzionalità di anteprima

L'accesso a selezione, le nuove funzionalità sono controllate dai flag di funzionalità. Periodicamente, Azure DevOps Services introduce nuove funzionalità inserendole dietro un flag di funzionalità. Le funzionalità di anteprima possono essere abilitate o disabilitate dai membri del progetto o dai proprietari dell'organizzazione. Per altre informazioni, vedere Gestire o abilitare le funzionalità.

Passaggi successivi