Olá a todos, e bem-vindos de volta.
Agora, no vídeo de hoje, vamos discutir sobre estratégias para a utilização das políticas de controle de serviços.
Agora, em uma visão geral de alto nível, há duas estratégias primárias que você pode usar para configurar
as etapas dentro de sua conta.
Uma é a estratégia baseada na lista de negação, e a segunda é a estratégia baseada na lista permitida.
Assim, no vídeo de hoje, vamos prosseguir e discutir sobre ambos em grande detalhe.
Agora, a primeira abordagem primária é a lista de negação, e na lista de negação, as ações são permitidas por
padrão no nível IP.
E então você especifica quais são os serviços e ações que você quer negar.
Agora, quando discutimos sobre organizações e políticas de controle de serviços, por
padrão, eles fazem uso desta estratégia baseada na lista de negação, e isto é conseguido através do uso da política de acesso total da CB, que
está ligada à raiz.
Agora, se examinarmos rapidamente como é esta política de acesso completo, esta é a declaração de política
onde tudo é permitido por padrão.
Agora, note que isto pode ser um pouco confuso porque a estratégia de negação é realmente permitida.
Portanto, isto é um pouco confuso para começar.
Agora, vamos também analisar isto rapidamente.
Agora, estou atualmente na organização que não tem o IPS habilitado.
Portanto, se você olhar para uma das contas aqui, se você olhar para as políticas, não há políticas
que estão associadas agora, nesta fase.
Sempre que ativamos as políticas de controle de serviços, nesta fase, vemos que existe uma política
primária que é criada e que é de acesso total.
O tipo é uma política gerenciada.
E se você olhar para isto, as metas das políticas são associadas à raiz e a todas as contas que fazem
parte agora desta abordagem de base.
Se você olhar para a declaração de política geral, ela está permitindo tudo.
Portanto, por padrão, tudo será permitido no nível SP e então você nega explicitamente qualquer serviço que queira
proibir.
Por exemplo, se você não quiser que ninguém se conecte com o serviço, você acrescenta uma declaração de negação explicitamente.
Agora note que, como esta é uma política gerenciada, existem certas restrições, portanto você pode ir em frente e criar
um novo conjunto de políticas.
Você não será capaz de realizar várias operações.
Por exemplo, se você quiser apagá-lo, vamos experimentá-lo como um acesso completo.
E se você vir na descrição, declara que não pode modificar e administrar a política.
Elas são lidas apenas grandes.
Agora com este básico entendido, vamos analisar alguns dos benefícios que este tipo de estratégia proporciona.
Como já sabemos que utilizando a estratégia de negação, o administrador de conta pode delegar todos os serviços
e ações até que você crie uma PCP anexa que negue um serviço específico.
Portanto, por padrão, tudo será permitido.
E então você acrescenta a política de negação explícita para negar um serviço ou ação específica.
Portanto, aqui precisamos observar que as declarações de negação requerem menos manutenção porque não é necessário
atualizar a política quando ela acrescenta novos serviços.
Portanto, a tem agora centenas de serviços desde que você permitiu explicitamente todos os serviços no nível ACP, você
realmente não precisa se preocupar porque mesmo se um novo serviço for lançado, os usuários terão acesso
a ele.
Considerando que eles têm as permissões apropriadas.
Além disso, um dos outros benefícios é que as declarações de negação geralmente utilizam menos espaço, facilitando assim
a permanência dentro do tamanho máximo das políticas de controle de serviços.
Agora, se você olhar para a política baseada na lista de negação da amostra, então pode parecer algo parecido com isto,
onde você tem uma declaração de negação em voz alta e então você tem uma declaração de negação explícita sobre a ação e o serviço.
Portanto, aqui a ação é a estrela Dynamo DB com este básico, vamos também analisar a estratégia número dois, que
é a lista de permissão.
Agora, para fazer uso da lista de permissões, o que você pode fazer, você deve substituir o ACP de acesso completo gerenciado
por um novo ACP que permita explicitamente apenas aqueles serviços e ações que você deseja permitir.
Agora você tem que lembrar que ao remover o ACP padrão de acesso completo, todas as ações para todos os serviços
são agora implicitamente negadas.
Esta é uma parte muito importante a ser lembrada.
E então, como todas as ações e serviços são implicitamente negados, você acrescenta um ACP personalizado que se sobrepõe a esta
negação implícita com a permissão explícita apenas para as ações que você deseja permitir.
Portanto, se você olhar para esta amostra permitir uma política baseada em listas, é assim que ela se parece.
Portanto, aqui se assume que este ACP de acesso completo não está associado às contas.
E então você acrescenta esta política específica que está permitindo certos serviços como o EC two star cloud watch
star.
Portanto, além destes serviços, os usuários não poderão realizar operações em nenhum deles.
Agora, antes de prosseguirmos, vamos também ter uma rápida demonstração associada a isto.
Agora, deixe-me também mostrar-lhe rapidamente uma demonstração.
Agora, nesta fase, observe que estamos apenas analisando o assunto do ponto de vista da demonstração para garantir que nossos conceitos
sejam melhor compreendidos.
Portanto, para a demonstração de hoje, tenho mais uma política de listas de políticas permitidas pela faculdade.
Portanto, se você examinar a política de lista de permissão, ela está associada à raiz e também está associada
a uma conta sandbox.
Agora, nesta etapa para que a política de listas possa entrar em vigor, você tem que garantir que seu pleno
acesso não esteja associado às contas.
Portanto, se você olhar para os alvos, ele está apenas associado à conta da gerência aqui.
Não está associado a nenhuma outra conta.
Portanto, se eu tiver que mostrar a vocês.
Assim, na raiz temos a conta de gerenciamento e a conta sandbox.
Portanto, esta política específica que temos, a política de lista de permissão, está associada se você olhar para a conta
sandbox e não há uma política de acesso completo aqui.
Portanto, vamos em frente e experimentemo-lo rapidamente.
Portanto, se você olhar para o conteúdo, está permitindo que o EC two star e cloud watch star agora possam testar as coisas.
Estou logado como usuário root em uma das contas dos membros.
Agora dentro de nós, uma vez que sabemos que apenas o EC dois e o observador de nuvens são permitidos, vamos tentar explorar
imediatamente outros serviços como o SES.
Você vê que temos um erro afirmando que há uma negação no ACP.
Vamos também tentar mais um serviço.
Vou dizer API gateway novamente, estamos recebendo um erro.
Da mesma forma, vamos tentar e c a este tempo e ec dois está funcionando perfeitamente bem.
Você poderá lançar instâncias, etc.
Muito bem.
Portanto, espero que com isso vocês tenham entendido o básico de permitir a lista e negar a lista.
Agora novamente, uma coisa que eu queria mostrar a vocês, vamos rapidamente olhar aqui.
Se você examinar esta política de contas sandbox que só permite políticas de listas.
Aqui não há uma política de acesso total.
E esta é a razão pela qual as coisas estão entrando em vigor.
Agora, antes de concluirmos algumas indicações importantes que precisamos anotar.
A primeira é que cada raiz ou você e conta devem ter pelo menos uma política de controle de serviços anexada.
E esta é a razão pela qual, se você quiser substituir a política de acesso completo padrão por uma ACP que limite a permissão,
então você deve anexar o SFP de substituição antes de remover o padrão.
Assim, por exemplo, nesta fase você verá que a conta sandbox tem uma política de lista de permitidos.
Portanto, na instância do momento, uma política deve ser anexada.
Portanto, se você quiser mudar de uma lista para uma lista de negação, então o que você tem que fazer, você tem que associar uma política
de lista de negação e então você pode remover a lista de permissão.
Ótimo.
Portanto, esta é a visão geral de alto nível sobre as estratégias que você pode usar.
Novamente, pelo que tenho visto em organizações, a maioria delas usa sua estratégia padrão baseada na lista de
negação.
Eles não optam por permitir a lista caso você esteja usando uma lista baixa, embora isso pareça
bom, mas também exige muito esforço.
E na maioria das organizações, a equipe de segurança ou a equipe que está gerenciando todas as ssps, elas
são bastante pequenas e não têm o tempo e os recursos necessários para gerenciar a política de listas de permissão,
além de outras configurações relacionadas à segurança em que têm que trabalhar como parte da infra-estrutura
geral.
Assim, com isto, o vídeo de hoje será concluído.