APRENDER. PRATICAR. EVOLUIR.1. Desenhar os dois lados do acesso
No exercício fictício, um fornecedor precisa de consultar relatórios por browser e operadores geridos usam um cliente com dependências adicionais. Não transformes essa necessidade num acesso genérico à subnet inteira. Descreve a aplicação, protocolos, nomes, utilizadores e requisitos do dispositivo. Secure Access oferece métodos de ligação distintos e o acesso por browser tem menos controlos de dispositivo do que o acesso com cliente. A escolha precisa de cumprir o contrato de acesso, não apenas abrir a página inicial. Se um requisito depende de postura não demonstrada naquele método, mantém a decisão de aceitação aberta e procura uma opção compatível.
2. Conector disponível não é aplicação disponível
Os conectores estabelecem ligações de saída para o serviço cloud, e precisam de resolver e alcançar os recursos privados. Um estado saudável no plano cloud não demonstra a rota interna, a resolução correta do nome nem a porta da aplicação. Na ficha, RC-A resolve o relatório para 10.30.0.10 mas encontra timeout TCP; RC-B resolve o mesmo nome e chega à aplicação. Essa diferença localiza uma hipótese no caminho de RC-A. Recolhe resultados por conector antes de alargar regras. Como qualquer conector do grupo pode servir os recursos associados, a aceitação deve cobrir a capacidade de cada membro alcançar esse conjunto.
3. Explicar a regra que realmente corresponde
Uma falha de autorização requer a identidade, o dispositivo, o recurso e a regra efetivamente selecionada. No caso fictício, um objeto de rede 10.30.0.0/16 sobrepõe-se a um recurso específico 10.30.0.10. Revê definições, ordem e eventos em vez de assumir que o nome mais específico terá sempre precedência. Os requisitos de postura participam na correspondência; uma regra que deixa de corresponder não demonstra, isoladamente, qual regra tratará o fluxo. A documentação também descreve um caso de alteração manual de steering em que mudanças posteriores no recurso exigem atualização manual dos endereços de steering. Confirma essa configuração separadamente quando o histórico corresponde ao caso.
4. Construir uma matriz que testa limites
A ficha contém seis ensaios planeados, não medições de um tenant. Inclui relatório permitido ao fornecedor, tentativa SSH proibida para o mesmo fornecedor, recurso permitido ao operador gerido, dispositivo que não cumpre a postura exigida, percurso por cada conector e perda de um membro do grupo. Para cada ensaio escreve resultado esperado, observação, responsável e decisão. A ausência de observação fica como não executado. Um login bem-sucedido não cobre todas estas linhas. Mantém também dependências da aplicação: redirecionamentos, nomes auxiliares e serviços autorizados devem entrar na matriz sem conceder uma wildcard indiscriminada para esconder falhas.
5. Continuidade e passagem para RUN
Dois conectores na mesma infraestrutura não demonstram independência de falha. Se ambos usam o mesmo resolver e a mesma saída, a avaria desse caminho pode afetar o grupo. O plano deve separar falha de processo, falha de host e dependência partilhada, além de capacidade remanescente. Os números reais exigem ensaio autorizado; a ficha não inventa throughput nem tempos de recuperação. Entrega a RUN mapas, regras, permissões, registos pesquisáveis e passos de recuperação com âmbito limitado. O laboratório TLS da aula anterior ajuda a interpretar uma camada, mas não executa Secure Access. Resumo: delimita o recurso, confirma o caminho de cada membro e aceita apenas os resultados observados.
RC-A: cloud saudável, DNS esperado, TCP timeout. RC-B: cloud saudável, DNS esperado, TCP e relatório funcionais. Dados fictícios para orientar diagnóstico.
Armadilhas comuns
Conector online como prova integral; dois membros como ausência de falhas comuns; regra nomeada como regra efetiva; uma wildcard como correção universal.
Tópicos relacionados: Zero trust · DNS privado · Resiliência
A aceitação combina identidade, política, caminho e serviço, incluindo os casos que devem ser recusados.
Referência: Private resource access · 350-701 SCOR v2.0, effective 2026-08-27; core component of CCNP Security