Modelo alternativo para políticas de aplicativo Web no SharePoint Online
As políticas de aplicativo Web são um conceito que permite que os administradores do SharePoint concedam ou neguem permissões a usuários e grupos para todos os sites em um aplicativo Web. Essas concessões de permissão e nega ter preferência sobre as permissões definidas nos sites no aplicativo Web e, portanto, são um mecanismo normalmente usado em cenários como estes:
- Conceda permissões de conta de serviço a todos os sites porque essa conta de serviço é usada para executar um processo em segundo plano que precisa manipular os dados em todos os sites. A conta de serviço também pode ser usada por um fluxo de trabalho para voltar ao SharePoint
- Conceder acesso somente leitura da equipe de suporte a todos os sites para que o engenheiro de suporte possa percorrer o site com o usuário final
- Negar aos usuários (por exemplo, depois de sair da empresa) acesso a todo o conteúdo
As políticas de aplicativo Web não existem mais no SharePoint Online e não há nenhuma implementação alternativa idêntica possível, no entanto, usando o modelo de segurança do SharePoint existente, você pode obter resultados semelhantes. Neste artigo e vídeo, você aprenderá mais sobre isso.
Concessão de acesso
Qual é o motivo comercial para essa concessão de permissão?
Antes de começar a implementar permissões, é importante entender por que uma concessão era necessária. As perguntas a serem feitas são:
- Conceder acesso a todos os dados em seu locatário do SharePoint Online é necessário? Fazer push e verificar se o acesso a todos os dados é absoluto deve dar suporte a um cenário de negócios
- O "um" está usando a permissão concedida é um aplicativo ou um usuário? Se for um aplicativo, talvez seja possível trabalhar com uma entidade de aplicativo com permissões de locatário do SharePoint Online, especialmente se este for um aplicativo desenvolvido internamente
O fluxograma abaixo está capturando estas perguntas:
Importante
Somente no caso de o acesso concedido ser consumido por um usuário ou um aplicativo que não seja compatível com entidades de aplicativo, caso você conceda acesso por meio de usuários ou grupos. Se possível, prefira entidades de aplicativo acima de usuários e grupos porque:
- As entidades de aplicativo são concedidas com escopo de todos os sites, o que significa que se um site for adicionado, a entidade de aplicativo também terá acesso a ele automaticamente. No caso de acesso de usuário/grupo, o respectivo usuário/grupo primeiro precisa ser adicionado ao novo site
- As entidades de aplicativo "substituem" a configuração de herança de permissão. Suponha que um sub-site tenha quebrado a herança de permissão e, como tal, conceder um proprietário de usuário/grupo, contribuir ou exibir o acesso ao site raiz concede acesso ao sub-site enquanto a entidade de aplicativo sempre terá acesso.
Conceder acesso usando entidades de aplicativo
Para todo o acesso não humano, é recomendável usar entidades de aplicativo conforme discutido anteriormente. Há duas abordagens para isso:
- Usando um aplicativo Azure AD: este é o método preferencial ao usar o SharePoint Online porque você também pode conceder permissões a outros serviços de Office 365 (se necessário) e você tem uma interface do usuário (portal do Azure) para manter suas entidades de aplicativo.
- Usando uma entidade de App-Only do SharePoint: esse método é mais antigo e funciona apenas para acesso do SharePoint, mas ainda é relevante. Esse método também é o modelo recomendado quando você ainda está trabalhando no SharePoint local, pois esse modelo funciona tanto no SharePoint local quanto no SharePoint Online.
Ambos os modelos são explicados detalhadamente no Accessing SharePoint usando um contexto de aplicativo, também conhecido como artigo somente aplicativo .
Conceder acesso por meio de usuários e grupos
Quando você quiser conceder acesso a todos os seus sites, você precisará conceder a um usuário ou a um grupo acesso a todos os sites individualmente. Esse modelo é diferente do que você costumava ter com políticas de aplicativo Web, mas é o único modelo que você pode usar para conceder a uma conta de usuário ou acesso de grupo a todos os sites.
Permissões que podem ser concedidas
Usando políticas de aplicativo Web, você tem a opção de conceder "Controle Completo" ou "Leitura Completa", que traduzido em permissões do SharePoint se resume a isso:
| Concessão de política de aplicativo Web | Permissão equivalente do SharePoint |
|---|---|
| Controle Total | Adicionar aos administradores da coleção de sites |
| Leitura Completa | Adicionar usando o nível de permissão "Leitura" (= visitantes do site) |
| Adicionar usando o nível de permissão "Controle Total" (= proprietários do site) | |
| Adicionar usando o nível de permissão "Editar" (= membros do site) |
Optamos deliberadamente por usar a função de administrador da coleção de sites para a concessão de "controle total", pois dessa forma evitamos o problema da herança de permissão. No SharePoint, os usuários podem interromper a herança de permissão e, como tal, conceder permissões exclusivas em objetos (por exemplo, sub sites, listas, itens de lista). Se isso foi feito e você, por exemplo, adicionar um usuário ao grupo de proprietários do site de coleção de sites, esse usuário não teria permissões no objeto com permissões exclusivas.
Importante
Se o cenário de negócios que você está implementando puder viver com as limitações de herança de permissão, você poderá usar qualquer uma das permissões descritas do SharePoint. Se você precisar garantir acesso 100% certo em todo o conteúdo, a única boa permissão do SharePoint é a função de administrador do conjunto de sites.
Conceder adicionando um usuário ou um grupo?
Você pode obter o mesmo resultado concedendo as permissões a um usuário ou a um grupo, mas ambos os modelos têm profissionais e con's.
| Categoria | Agrupar | Usuário |
|---|---|---|
| Clarity | Um grupo pode conter uma ou mais contas, normalmente não visíveis para os outros administradores da coleção de sites | A conta de usuário está sempre visível, não há dúvida sobre isso |
| Manutenção | Você pode facilmente conceder acesso adicionando novos membros ao grupo | Novos membros devem ser adicionados a todos os sites |
| Prova de adulteração | Um grupo pode proteger as contas reais que têm acesso (por exemplo, conta legal) e outros administradores são menos propensos a remover as permissões para o grupo | Há transparência total, outros administradores podem ser mais propensos a remover os usuários "estranhos" de seu site |
Importante
Conceder permissões usando um grupo é um modelo mais flexível.
E os sites de equipe modernos (também conhecidos como sites de grupo)?
Sites de equipe modernos são sites de equipe do SharePoint conectados a um grupo do Microsoft 365. Esse grupo do Microsoft 365 atua como um modelo central para conceder acesso a todos os serviços em cima desse grupo (por exemplo, Site do SharePoint, caixa de correio exchange, Planner, ...). Para esses sites, você tem duas opções para conceder acesso:
- Adicione contas de usuário (sem grupos) aos membros ou proprietários do grupo Microsoft 365 conectado ao site de equipe moderno. A vantagem dessa abordagem é que a permissão concedida se aplica a todos os serviços que usam esse grupo, mas ao avaliar políticas de aplicativo Web isso normalmente não é relevante
- Tratar o site de equipe moderno como um site "normal" e conceder permissão como descrito em capítulos anteriores
Importante
Recomendamos conceder permissões no nível do SharePoint, portanto, trate os sites de equipe modernos como sites de equipe clássicos regulares do SharePoint. Essa abordagem se alinha ao que as políticas de aplicativo Web estavam fornecendo.
Concessão de permissões usando o PowerShell PnP
Os scripts abaixo mostram uma maneira fácil de conceder acesso usando o PowerShell PnP e podem ser uma boa base inicial para sua implementação. Os scripts abaixo não levam em conta o seguinte:
- Get-PnPTenantSite atualmente não está enumerando sites de equipe modernos
- Get-PnPTenantSite não está ciente de vários geográficos
- O desempenho não é ideal, pois os scripts estão em execução sequencialmente, não há execução paralela
Como os usuários criam continuamente novas coleções de sites, é importante executar esses scripts regularmente, idealmente como uma tarefa agendada.
Observação
O PnP PowerShell é uma solução de software livre com uma comunidade ativa de suporte. Não há nenhuma SLA para o suporte da ferramenta de software livre por parte da Microsoft.
Importante
Se o locatário tiver muitas coleções de sites, a abordagem usando um aplicativo desenvolvido personalizado será uma solução melhor para você.
Controle Total
Para dar aos usuários controle total a sites específicos (ou todos) do SharePoint, você pode usar o SharePoint PowerShell para tornar os usuários de destino administradores do Site Collection dos sites de destino (incluindo todos). Isso pode ser feito por um Administrador global ou administrador do Serviço do SharePoint. É recomendável que o acesso seja adicionado conforme necessário e, em seguida, removido. Por exemplo, o script abaixo atribui uma lista de administradores a todas as coleções de sites em um locatário. O exemplo usa os comandos PnP (Padrões e Práticas) do SharePoint do PowerShell para tornar dois usuários administradores de todas as coleções de sites no locatário.
# comma-separated list of users and groups to be added
$adminAccounts = "admin1@contoso.onmicrosoft.com","admin21@contoso.onmicrosoft.com"
# Specify the tenant here
$tenant = "contoso"
# Note: This example assumes that you are managing your credentials in Windows as documented here:
# https://github.com/SharePoint/PnP-PowerShell/wiki/How-to-use-the-Windows-Credential-Manager-to-ease-authentication-with-PnP-PowerShell
write-host "Connecting to https://$($tenant)-admin.sharepoint.com"
Connect-PnPOnline -Url "https://$($tenant)-admin.sharepoint.com"
#Note: we are only fetching the root site collection and any site collection in the /sites path
#Update filters here accordingly to match your requirements
write-host "Getting list of site collections"
$sitecollections = Get-PnPTenantSite | where {($_.Url -like "*$($tenant).sharepoint.com/") -or ($_.Url -like "*$($tenant).sharepoint.com/sites/*")}
foreach($sitecollection in $sitecollections) {
write-host "Adding administrators to $($sitecollection.Url)"
Set-PnPTenantSite -Url $sitecollection.Url -Owners $adminAccounts
}
Leitura Completa
Para fornecer aos usuários leitura completa para sites específicos (ou todos) do SharePoint, você pode usar o SharePoint PowerShell para adicionar os usuários de destino a uma função de leitura do conjunto de sites. Isso pode ser feito por um Administrador global ou administrador do Serviço do SharePoint. As etapas gerais incluem definir uma Função de Leitura do SharePoint para o conjunto de sites ou reutilizar uma existente e, em seguida, atribuir usuários ou grupos à Função. Para usar Azure AD grupos, incluindo aqueles com associação dinâmica, para controlar o acesso aos recursos, consulte: Gerenciar o acesso a recursos com grupos do Azure Active Directory. O exemplo usa o PnP (Padrões e Práticas) do SharePoint dos comandos do PowerShell para criar uma nova Função de Leitura para todas as coleções de sites no locatário.
# Specify the tenant here
$tenant = "contoso"
# Note: This example assumes that you are managing your credentials in Windows as documented here:
# https://github.com/SharePoint/PnP-PowerShell/wiki/How-to-use-the-Windows-Credential-Manager-to-ease-authentication-with-PnP-PowerShell
write-host "Connecting to https://$($tenant)-admin.sharepoint.com"
Connect-PnPOnline -Url "https://$($tenant)-admin.sharepoint.com"
# Note: we are only fetching the root site collection and any site collection in the /sites/ path
# Update filters here accordingly to match your requirements
write-host "Getting list of site collections"
$sitecollections = Get-PnPTenantSite | where {($_.Url -like "*$($tenant).sharepoint.com/") -or ($_.Url -like "*$($tenant).sharepoint.com/sites/*")}
foreach($sitecollection in $sitecollections) {
write-host "Set FullRead for MyGroup to $($sitecollection.Url)"
Connect-PnPOnline -Url $($sitecollection.Url)
New-PnPGroup -Title 'FullReader'
Set-PnPGroupPermissions -Identity 'FullReader' -RemoveRole 'Full Control' -AddRole 'Read'
}
Conceder permissões usando um aplicativo desenvolvido personalizado
Um modelo alternativo para a abordagem do PowerShell é criar um aplicativo em segundo plano que enumera todas as coleções de sites (incluindo sites de equipe modernos, sites OneDrive for Business, entre locais ao usar o Multi-Geo), verifica se o usuário/grupo necessário tem acesso e se não adiciona esse. A arquitetura de tal aplicativo pode ser tão simples quanto a definida abaixo:
- Você começa com a definição de um aplicativo no Azure AD para o qual você configura o uso somente do aplicativo (consulte Conceder acesso por meio de Azure AD Somente aplicativo) e conceder controle total em todas as coleções de sites
- Você cria um aplicativo C# que se autoriza usando o aplicativo Azure AD que você definiu na etapa 1 e itera em todas as coleções de sites (isso pode incluir coleções de sites OD4B) para adicionar as contas/grupos necessários se eles não estiverem presentes
- Esse aplicativo C# precisa ser hospedado e agendado para ser executado em intervalos regulares. Usar um trabalho Web do Azure é um bom modelo para fazer isso, mas o mesmo pode ser feito executando o aplicativo como uma tarefa agendada em um servidor
Como parte dessa orientação, criamos um aplicativo para que você comece com isso. O exemplo é chamado Governance.EnsurePolicy e pode estar no repositório PnP do SharePoint.
Observação
Esse cenário pode ser expandido ainda mais para um aplicativo que concede condicionalmente e remove permissões. Por exemplo, os funcionários do helpdesk poderiam solicitar acesso a um determinado site por meio da criação de um item de lista do SharePoint, o aplicativo vê isso e concede acesso por x horas... e remove as permissões posteriormente. Este aplicativo também mantém um log mostrando quem recebeu acesso a qual site e quando.
Negando acesso
Substituir Negar todas as políticas usando controles de acesso do Office 365 e do SharePoint
Não há nenhuma política "Negar Tudo" no Office 365, mas nossa abordagem recomendada é gerenciar as permissões usando políticas de controle de acesso do SharePoint O365. O cenário precisa incluir usuários, aplicativos e dispositivos. Algumas dessas políticas de controle de acesso são descritas abaixo.
Para impedir que usuários específicos acessem Office 365 recursos, incluindo o SharePoint, siga as instruções descritas aqui: Remover um ex-funcionário do Office 365. Por exemplo, para cortar o acesso a um funcionário que deixou a organização. Isso pode ser feito por um administrador de gerenciamento de Administrador global ou usuário usando o centro de Office 365 Administração ou script usando o PowerShell.
Para limitar o compartilhamento externo para que fornecedores, clientes ou clientes tenham acesso apenas a recursos específicos, siga as diretrizes aqui: Gerenciar o compartilhamento externo para seu ambiente do SharePoint Online. Por exemplo, você pode configurar um site de extranet do SharePoint Online focado na colaboração externa.
Para bloquear ou permitir o compartilhamento com usuários externos de domínios específicos no nível de coleção de locatários ou sites, siga as instruções aqui: Compartilhamento de domínios restritos no SharePoint Online e OneDrive for Business. Por exemplo, limitar o compartilhamento com apenas parceiros de negócios específicos em domínios conhecidos. Isso pode ser configurado por um Administrador global ou administrador do Serviço do SharePoint.
Com Office 365 Central de Segurança e Conformidade, você pode usar os recursos de auditoria para acompanhar a atividade do arquivo. Saiba mais com os seguintes artigos:
- Auditoria de todas as coleções de sites do SharePoint usando a central de conformidade e segurança do Office 365: pesquise o log de auditoria na Central de Conformidade & de Segurança Office 365. Essa abordagem fornece auditoria de todos os seus sites, um modelo de relatório flexível e você pode usar as API's para fazer o processamento personalizado dos dados de auditoria.
- Use Office 365 Cloud App Security: Office 365 Cloud App Security fornece informações sobre atividades suspeitas em Office 365 para que você possa investigar situações potencialmente problemáticas e, se necessário, tomar medidas para resolver problemas de segurança. Com Office 365 Cloud App Security, você pode fazer todos os seguintes procedimentos:
- Veja como os dados da sua organização no Office 365 são acessados e usados
- Definir políticas que disparam alertas para atividades atípicas ou suspeitas
- Suspender contas de usuário que exibem atividades suspeitas
- Exigir que os usuários façam logon novamente em aplicativos Office 365 após um alerta ter sido disparado
Com Office 365 Central de Segurança e Conformidade, você também pode bloquear o compartilhamento externo de documentos confidenciais definindo quais tipos confidenciais estão em sua organização (escolha entre um dos muitos modelos ou crie seus próprios tipos confidenciais personalizados). Saiba mais sobre tipos confidenciais internos aqui: Tipos de informações confidenciais. Saiba mais sobre como criar seus próprios aqui: criar tipos de informações confidenciais personalizados.
Para usar Azure AD grupos, incluindo aqueles com associação dinâmica, para controlar o acesso aos recursos, consulte: Gerenciar o acesso a recursos com grupos do Azure Active Directory. Por exemplo, os grupos podem ser configurados para remover membros cuja conta não está habilitada. Além disso, a Proteção de Identidade do Azure Active Directory (parte do Azure AD Premium) permite que os administradores identifiquem entradas arriscadas e bloqueiem ou exijam autenticação multifator.
Para bloquear ou limitar o acesso em dispositivos não compatíveis ou não gerenciados, a funcionalidade chegará em breve, o que aproveita as políticas de acesso condicional do Azure Active Directory. Usando essa política, você pode bloquear o acesso a aplicativos avançados em dispositivos não gerenciados e permitir acesso somente ao navegador sem a capacidade de baixar, imprimir ou sincronizar. Isso evita o vazamento de dados em dispositivos não gerenciados. Isso será configurável por um Administrador global ou administrador do Serviço do SharePoint.
Para bloquear o acesso em locais de rede não confiáveis, você pode usar a política baseada em localização para configurar uma lista de endereços IP confiáveis dos quais o acesso é permitido. Siga as instruções aqui: Controlar o acesso ao SharePoint e ao OneDrive com base em locais de rede.