Sugerir tradução
Outras sugestões:

progress indicator
Sem sugestões.
TechNet Magazine > Home > Todas as edições > 2009 > TechNet Magazine Julho 2009 >  Inspeção de segurança: Considerações sobre iden...
Exibir Conteúdo: Lado a LadoExibir Conteúdo: Lado a Lado
Este é um conteúdo traduzido por máquina que os membros da comunidade podem editar. Incentivamos você a melhorar a tradução clicando no link Editar associado a qualquer sentença abaixo.
Security Watch Thoughts on Identity, Part 2
Jesper M. Johansson

Last month, I embarked on the somewhat daunting task of describing identity systems and, in particular, why we still don’t have an industry standard one. First, I defi ned what identity really is, and why we care about identities in digital systems. Then I covered the problems with identity—notably, the fact that we all have not just one identity, but many. Then I pointed out that if you don't believe you've got enough, you can always create, or buy, a few more.
As discussed, this creates a problem in authentication because we typically think of identity as an ontological identity—a representation of a real, physical person. In most systems, that relationship turns out to be an unnecessary complication. Most identities don't need to be representative of the real-world entity they identify or even identify any real-world entity at all—in fact, it's often undesirable for them to do so.
Finally, I covered how authentication works—specifically, that the really interesting part happens in the socio-technical system where the consumer of some service provides proof of identity. I noted that a successful digital-identity system must fulfill certain criteria and conform to a set of basic principles. In Part I, I covered the first two such principles: "The identity provider is at least as sensitive as the most sensitive relying party" and "Permit the enterprise to protect its customer relationships and to own and control information that it deems as business confidential." Here, in Part II, I conclude the series by covering additional principles that successful digital identity systems must meet.

Be Platform Agnostic
Because they're in business to make money, companies will cater to their customers. They'll endeavor to reduce the amount of "friction" required for the customer to hand over their hard-earned dollars. Any smart business will avoid making requirements of its customers that reduce the customer's likelihood of staying a customer, nor any requirement that reduces the customer base. That means that no mainstream business will use an identity solution that excludes some number of its customers from being able to spend money at the business. Likewise, no rational business is going to implement an identity solution that requires its customers to go to extra lengths to install new software or components to in order to use it.
A similar implementation decision will be made for an identity solution that works for only a subset of customers. Let's say that such a solution costs $5 million to implement. Let's also say that the free cash flow for the business—the proportion of its revenue that is not earmarked for any current development project—is 7 percent of its gross revenues. In this case, the company would need to generate an additional $71.5 million in revenues from the solution just to cover the cost of implementation. That is a significant number, especially if it provides only an incrementally improved solution for a subset of customers. There would have to be a measureable impact to the security of those customers to justify it. Few, if any, identity solutions will meet those requirements.

Work Well with the User's Cognitive Framework
Ultimately, an identity system that people use must work within the human cognitive framework. Surprising as it may seem, human beings didn't evolve to deal with digital identity systems. Nor, it would seem, were they particularly intelligently designed to do so. Many scholars in cognitive science claim that the fundamental wiring of human beings was designed to deal with life in a cave, foraging for food (and mates), and trying to survive attacks by saber-toothed cats. Undoubtedly, mankind has spent a lot longer living in caves than in cubicles and a lot longer communicating with smoke signals than electrons. In cave life, we had little use for digital identities, and, consequently, we didn't evolve with wiring specifically geared to understanding them.
Consequently, our mental model of the world doesn't include managing hundreds of digital identities to safeguard electronic transactions. However, it is perfectly reasonable to assume that people had to use code words while living in caves. Certain words likely had special meaning and got special results. " Please" probably had some kind of forerunner in caveman-speak, just to mention one.
I'm not saying that using code words, or the current equivalent—passwords—is the only reasonable way to authenticate a digital identity. I am saying that if a majority of users is to accept your digital-identity system, it must not require them to change their cognitive model of the world. Cognitive models are largely hard-wired. We can certainly deal with systems that don't fit with cognitive models—but doing so comes at a cost: stress, frustration and anger. Using such a system would have to include a benefit that outweighs the cost of those factors. By contrast, an intuitively obvious system will receive greater levels of adoption even if it provides fewer other benefits.

Guarantee Two-Way Identification
Among the most important aspects of a digital-identity system—and one that, unfortunately, isn't well understood by the users of such systems—is the identification of the relying party and/or identity provider to end users. The relying party—or more commonly, the service provider—is often implicitly trusted by end users. That's why phishing attacks—that is, stealing an identity by posing as a trusted party—are so incredibly successful. It doesn't take much to fool a sufficient number of users to reveal their secrets.
A successful digital-identity system must permit all parties to authenticate themselves in ways that fit the cognitive model of the system user. Unfortunately, this crucial aspect of the system is often ignored by the service providers. In my "Security is About Passwords and Credit Cards" series, I illustrated how a popular credit-card company actively refuses to identify itself to you before you authenticate to it. At this writing, it gives me no pleasure to report that Discover still refuses to show a user a digital identity before requesting the user to authenticate. If you go to the Discover Card Web site, you'll be redirected and asked for your username and password without any opportunity to verify that you aren't sending your credentials to a phishing site. One can only wonder how many Discover accounts have been compromised because cardholders have been conditioned to provider their usernames and passwords to anyone who asks.
On the other hand, it's impossible to argue that SSL has been a successful component of digital-identity systems. The fact that it permits user authentication is virtually unknown, at least to users. The fact that it is primarily designed to prove server identity is ignored by many service providers. Instead, SSL is used as an expensive key-exchange mechanism and as a primary source of revenue to companies that issue the certificates that nobody bothers to inspect. As currently implemented, SSL is failing as a component in digital-identity systems. It doesn't work with the user's cognitive models and while it permits service providers to identify themselves, this identification is presented to end users so poorly that most don't understand how to use it.
A successful end-to-end digital-identity system must make identification of both parties to the transaction an integral part of the authentication workflow. However, a digital-identity system must first and foremost solve the digital-identity problem. Managing digital identities, refreshing digital identities, storing digital identities, transmitting claims proving digital identities, verifying digital identities, and granting appropriate access to digital identities are all problems that are difficult enough on their own. If a digital-identity system can be used to solve other problems as well, that's a bonus—but it shouldn't be among the system's design goals.
A perfect example is phishing. Phishing is a human problem, not a digital-identity one. Phishing attacks human beings, not technologies. Ultimately, the only solution to phishing will be to help people make more intelligent security decisions. An identity system can certainly do that, but not at the expense of the core purpose of such a system which is to help users and service providers identify themselves to each other.

Permit the User to Provide Claims with an Assurance Level Appropriate to the Service Provided
Most users use many different information services. Some services provide highly sensitive information, such as bank-accounts or retirement-savings accounts. Some provide information that may be sensitive in some cases, such as e-mail. Others provide information of value to users' reputation, such as social-networking sites. Still others provide information that isn't at all sensitive, such as a software supplier's technical-support site.
Yet, despite the different levels of sensitivity involved with these services, many try to use the same identity. For example, the same identity I use to access my e-mail is requested every time I try to get product information from my software supplier; if I chose to do so, I could manage my banking information with the same identity. I believe that my e-mail has significant value; my banking information definitely does. Software product information? Not so much. Because I could easily get a salesperson to print it out and even drive 30 miles to deliver it all, I consider that information to have virtually no value at all.
This type of overloaded use of credentials is endemic to identity systems. It is called "single sign-on." In some ways, single sign-on is an appealing concept. In an enterprise environment, it has great business value and, if it isn't already available, it should be added to the agenda right now. Outside the enterprise, where we deal with information of very disparate value, single sign-on is dangerous. If you walked up to your newsstand and the salesperson asked you for two forms of identity before you were allowed to buy your morning paper, you'd surely object, but the same request made before you can withdraw $2,000 from your bank account or drive away in a new car wouldn't raise your eyebrows.
The same separation of claims must be supported by a successful digital-identity system. Users should be able to present a set of credentials appropriate to the level of risk represented by the data or services they arerequesting.
Single sign-on is inappropriate in broadly used digital-identity systems. It's certainly acceptable to use single sign-on to access the system itself, but the actual credentials presented to the relying party—the service provider—must be commensurate with the service the user is receiving. For that reason, it's highly likely that, whatever form a successful digital-identity system takes, it will support a two-layer identity system: one layer to sign into the digital-identity system itself and another to actually identify the user to the relying party. A system that provides this facility nicely is Microsoft's InfoCard system.
Better still, a good digital-identity system should make it easy for the user to submit a set of claims defined for a service to that service, but warn the user when submitting them to another service. In other words, the digital-identity system should help users identify the service providers they are attempting to access.

Focus on Consistency of the Claims as Opposed to a Canonical Identity
A successful digital-identity system must respect the individual's right to privacy. While the exact expectation of privacy differs greatly between cultures, the overall human desire for privacy, however it is defined, is indisputable. You might even call privacy an innate human need. It can easily be considered a safety need, under Abraham Maslow's hierarchy of needs shown in Figure 1. Maslow, writing in pre-Internet times, may simply have excluded it because privacy was not as much of an issue in 1943.
Figure 1 Maslow’s Hierarchy of Needs
If we accept privacy as a human need, or at least a desire, we can discuss that need in the context of a digital-identity system. Consider, for example, a system such as a discussion board about your favorite hobby. Most such discussion boards require authentication; in other words, they implement a digital-identity system. What identity do you use for that board? Do you use your real name or do you go by a moniker such as "Deep Diver 13"? Most of us would probably use some kind of nickname. Requiring us to register a valid phone number and home address for such a purpose would probably be considered a violation of privacy. Requiring us to use a digital identity that maps to our physical person, and which also maps to our health records, is almost certainly going to be considered a violation of privacy.
I've often said that, for most purposes, digital-identity systems need only be concerned with whether a user can lie consistently. A user doesn't have to bind his or her digital identity a given system to a physical identity or even to a digital identity used in another system. Users should be able to conceal their true identities and hide links to other systems, whether at the same sensitivity level or other ones, by using different digital identities.
The system, in essence, must focus on the consistency of the claims presented by the user, rather than on binding those claims to a canonical, typically ontological, identity. As long as the same set of claims is presented, the user should be accepted, and for most purposes, that is all the system requires. Take a retail Web site, for instance. The retailer really doesn't need to care about who a user actually is, unless the laws governing the transaction require it. The retailer needs to care only about whether users can present the same lies today as when they set up their accounts, and whether their methods of payment still work. In most cases, that is sufficient to make a successful transaction. Many identity systems overdo the "identity" part and attempt to tie identity to a person, as opposed to a user.
Perhaps even more important than providing the user the ability to protect his or her ontological identity is the ability to make it easy to manufacture identities. A digital-identity system is, after all, just software. It could very easily help users manage identities to maximize user privacy. A digital-identity system that implements this ability stands a much better chance of success than one that ignores it.

Don't Mix Trust Levels
One interesting feature of the digital- identity systems is that they often require use of an identity provider that differs from the service provider. If the trust the user places in the service provider doesn't match the level of trust placed in the identity provider, there's obvious discord. If the user trusts the service provider, but not the identity provider that the service provider uses, the user may be reluctant to use the service provider for that very reason. An interesting example where this might occur is Formerly a Microsoft subsidiary, Expedia uses Microsoft Passport, now Windows Live ID, for authentication, as shown in Figure 2.
Figure 2 Expedia supports sign-in with Windows Live ID.
Now let's say that a user trusts Expedia, but not Microsoft. If Expedia required use of Windows Live ID (which it doesn't) would that user be willing to use Expedia at all? Maybe. Maybe not. Whichever the case may be, the user is able to use an Expedia identity on Expedia as opposed to a Windows Live ID one, and some users may prefer that.
Of course, the same trust issue goes the other way. If a user trusts Microsoft but not Expedia, the user may be unwilling to use Expedia if it requires use of Windows Live ID. Perhaps the user has used Windows Live ID for highly sensitive purposes, such as protecting bank-account information through MSN Money. In that case, some users may be reluctant to use the same Windows Live ID that protects their bank-account information to book travel reservations.
This property of a system is very much in line with the previous item about requiring claims in accordance with the sensitivity of the information that they protect. In a nutshell, the user must trust certain parties in any transaction, but the extent to which those parties are trusted may differ. Mixing trust levels is likely to provide users with reasons to distrust the system.

Don't Violate Laws or Regulations—or Expectations
Few issues in information-security management today are as vexing as legal and regulatory compliance. While many security professionals probably don't want to think of lawyers as their best friends, attorneys are becoming absolutely necessary to the cause. Privacy is a matter of law and regulation, and those laws and regulation differ in different jurisdictions.
This raises an interesting issue. Let's say that a particular digital-identity system is actively recruiting relying parties. The identity claims get picked up by a relying party that provides information that isn't very sensitive, such as access to a discussion forum. The relying party provides a level of security for the identity claims commensurate with the sensitivity of the information they serve—in other words, very little. Now let's say that the identity provider signs a contract with a credit-reporting agency, and consequently modifies the claims packet to include a national ID number or some representation of it. This new claim is suddenly being transmitted to the discussion board. The discussion board's security protocols don't provide the security level required for such information, so it may violate various laws and regulations.
These are typically simple issues to work around, and if the remaining principles are followed, it's unlikely that this one will be violated, but it's still an important consideration. Likewise, digital-identity systems that are used across national borders must be sensitive to different rules. Asking for a particular piece of identifying information may be perfectly legitimate in one jurisdiction; asking for the same information somewhere else may be illegal or subject to regulation.
For example, asking for age as part of a digital-identity system makes the identity provider subject to the Children's Online Privacy Protection Act in the United States and similar laws in other jurisdictions. If an identity provider makes that information available to any relying party that doesn't request it, the compliance requirement is transferred to that relying party even if it didn't want the information. Obviously, it's critical that a digital-identity system is capable of respecting those types of laws and regulations and not put anyone in violation.

Permit All User-facing Attributes to Be Modified or Deleted
Finally, a digital identity system must put users in control of their own data. This is perhaps the most controversial of all the principles. The identity providers often view the information they collect as business data. Users, by contrast, consider their names, addresses and other information their personal property to use as they see fit, which might include revoking someone's right to have it.
Clearly, current practices already reject users' rights to completely control access to their information; anyone who has attempted to get one of the three U.S. credit-reporting agencies to delete personal information can attest to this. Even if that information is documented as incorrect, the credit-reporting agencies are usually happy to keep selling it. Accuracy and approval by the subject of the data is irrelevant. Discussing the ethics of a system where someone else is permitted to profit from your identifying information without your consent is beyond the scope of this article, but for a system to be widely accepted by users, a digital-identity system must not put users' information beyond their control.
This means that all information must be modifiable, including aspects such as usernames. A very common type of username is an e-mail address. In spite of the fact that using an e-mail address as an identifier may violate some of the separation principles discussed earlier, it also makes sense to use an e-mail address as an identifier because it's guaranteed to be unique. However, it is also a mutable entity and another person is often granted a previously used e-mail address. That means that the identity system must not only permit a user to modify his or her user ID if it's an e-mail address, but also that the system must deal with problems that occur when new users pick up old addresses. What would happen if a new user tried the forgotten-password feature and received access to another user's account information? That's probably not optimal. Decommissioning an e-mail address is a perfectly valid use-case. The digital identity system needs to deal with this contingency as well as with other changes in information, such as names.

Clearly, digital-identity systems are quite complicated. Not only are they complicated to build, as we already knew, but the principles they need to comply with to be broadly successful are complex as well. We can draw two conclusions from this discussion. First, digital identity systems must be simplified. We've spent several years trying to design systems that work around users, not through users. Digital-identity systems must provide users with control of their information without making undue requests of them. At the extreme end, they must support users who wish to be anonymous. Likewise, they must not require businesses to expend more on implementing the system than the system is worth.
Second, digital-identity systems must provide identification services that are appropriate to the way they are used. They must provide for multiple levels of claims to support the assurance level required for the systems that those claims are being used to authenticate. In other words, on the Internet as a whole, single sign-on is probably going to be appropriate only to the system used to manage identities—it won't be the identity itself.
Whether we will ever see a single, very successful system that meets all these principles remains to be seen. Most people agree that we are not there yet.

Jesper M. Johansson is Principal Security Architect for a well-known Fortune 200 company, working on risk-based security vision and security strategy. He is also a contributing editor to TechNet Magazine. His work consists of ensuring security in some of the largest, most distributed systems in the world. He holds a Ph.D. in Management Information Systems, has more than 20 years experience in security and is a Microsoft Most Valuable Professionals in Enterprise Security. His latest book is the Windows Server 2008 Security Resource Kit (Microsoft Press, 2008).

Inspeção de segurança Idéias sobre identidade, parte 2
Jesper M. Johansson

No mês passado, eu embarcou na tarefa um pouco desanimador de descrever sistemas de identidade e, em particular, por que nós ainda don’t têm um setor um padrão. Primeiro, eu defi ned que identidade realmente é e por que nos interessa identidades em sistemas digitais. Em seguida, abordei os problemas com identidade — particularmente, o fato de que todos temos não apenas um identidade, mas muitos. Em seguida, mencionei que se você não acredita que você tem suficiente, você pode sempre criar ou comprar, mais alguns.
Conforme discutido, isso cria um problema na autenticação porque achamos que normalmente de identidade como uma identidade ontological — uma representação de uma pessoa real, física. Na maioria dos sistemas, esse relacionamento é uma complicação desnecessária. A maioria das identidades não precisam ser representativo da entidade do mundo real que identificam ou até mesmo identificam qualquer entidade de mundo real em todos os — na verdade, geralmente é indesejável para que eles fazê-lo.
Finalmente, abordei como funciona a autenticação — especificamente, que a parte realmente interessante acontece no sistema socio técnico em que o consumidor de algum serviço fornece prova de identidade. Observei que um sistema de identidade digital bem-sucedido deve atender a determinados critérios e estar de acordo com um conjunto de princípios básicos. Na parte 1, abordei como primeiro dois princípios: "O provedor de identidade é menos confidencial como a parte confiante mais confidencial" e "permitir a empresa para proteger seus relacionamentos com clientes e para o proprietário e controlar informações que ele considere como comerciais confidencial". Aqui, na parte II, concluir a série abordando princípios adicionais que devem atender aos sistemas de identidade digital bem-sucedida.

Ser plataforma não reconhece
Porque eles estão na empresa fazer dinheiro, empresas irão atender seus clientes. Eles vai se esforçar para reduzir a quantidade de "conflito" necessário para o cliente entregar suas dólares rígido acumulado. Qualquer empresa inteligente evitará fazer requisitos de seus clientes que reduzem a probabilidade do cliente de ficar um cliente, nem qualquer requisito que reduz a base de clientes. Que significa que não comerciais importantes usará uma solução de identidade que exclui alguns de seus clientes sejam capazes de gastar dinheiro na empresa. Da mesma forma, não comerciais racional será para implementar uma solução de identidade que requer a seus clientes ir para comprimentos extras instalar novos softwares ou componentes para usá-lo.
Será feita uma decisão de implementação semelhante para uma solução de identidade que funciona para apenas um subconjunto dos clientes. Digamos que tal solução custa US$ 5 milhões para implementar. Vamos dizer também que o dinheiro livre fluxo para a empresa — a proporção da sua receita não consignada para qualquer projeto de desenvolvimento atual — é 7 % do seus receitas brutas. Nesse caso, a empresa precisará gerar um milhão de 71.5 $ adicionais em receitas da solução apenas para cobrir o custo da implementação. Que é um número significativo, principalmente se ele fornece apenas uma solução de forma incremental aperfeiçoada para um subconjunto de clientes. Existe teria que ser um impacto measureable para a segurança desses clientes para justificar a ele. Alguns, se houver, soluções de identidade atenderá esses requisitos.

Trabalhar bem com Framework Cognitive do usuário
Por fim, um sistema de identidade que as pessoas uso deve trabalhar dentro a estrutura cognitiva humana. Surpreendente como ela pode parecer, seres humanos não evoluir para lidar com sistemas de identidade digital. Nem poderia parecer, foram eles particularmente inteligentemente criados para fazer isso. Muitos scholars em ciência cognitiva solicitar que o cabeamento fundamental de seres humanos foi projetado para lidar com vida em um cave foraging de alimentos (e parceiros) e tentando sobrevivem a ataques por toothed namely gatos. Sem dúvida, humanidade gastou muito mais vida em caves que em baias e comunicação muito mais com sinais rápido (smoke test) que electrons. Na vida cave, tivemos de pouco uso para identidades digitais e, conseqüentemente, nós não evoluir com cabeamento voltado especificamente para noções básicas sobre eles.
Conseqüentemente, nosso modelo mental do mundo não incluir o gerenciamento centenas de identidades digitais para proteger transações eletrônicas. No entanto, é perfeitamente razoável pressupor que as pessoas tinham usar palavras do código enquanto que em caves. Certas palavras provavelmente tinham um significado especial e obtive resultados especiais. " Por favor"provavelmente tinha algum tipo de antecessor falar em caveman, apenas para mencionar um.
Não Estou dizendo que usar palavras de código ou o equivalente atual — senhas — é a maneira razoável somente para autenticar uma identidade digital. Estou dizendo que se a maioria dos usuários é aceitar o sistema de identidade digital, ele deve não exigi-los para alterar seu modelo cognitivo do mundo. Os modelos de cognitivas são amplamente hard-wired. Nós certamente pode lidar com sistemas que não se ajustarem com modelos cognitivas — mas fazer assim tem um custo: estresse, frustração e irritação. Usando como um sistema teria que incluem um benefício que supera o custo desses fatores. Por outro lado, um sistema intuitivamente óbvio receberá níveis superiores de adoção, mesmo que ele fornece menos outros benefícios.

Garantia de identificação bidirecional
Entre os aspectos mais importantes de um sistema de identidade digital — e outra que, infelizmente, não é bem compreendido pelos usuários de tais sistemas — é a identificação de terceira parte confiável e/ou provedor de identidade para os usuários finais. A terceira parte confiável — ou o mais comum, o provedor de serviços — freqüentemente implicitamente é confiável para os usuários finais. É por isso que ataques de phishing — ou seja, roubar uma identidade por apresentando como um parceiro confiável — forem tão incrivelmente bem-sucedidas. Ele não levar muito enganar um número suficiente de usuários para revelar seus segredos.
Um sistema de identidade digital bem-sucedido deve permitir que todas as partes para se autenticarem de maneiras que ajustar o modelo de percepção do usuário do sistema. Infelizmente, esse aspecto crucial do sistema geralmente é ignorado pelos provedores de serviço. Em minha série de "segurança é sobre senhas e cartões de crédito", eu ilustrado como uma empresa de cartão de crédito popular ativamente se recusa a identificar-se para você antes de autenticar para ele. Quando este texto, ele me dá não prazer ao relatório que Discover ainda se recusa a mostrar uma identidade digital de um usuário antes de solicitar o usuário seja autenticado. Se você for para o Discover Card site, você vai ser redirecionado e fornecer seu nome de usuário e senha sem qualquer oportunidade de verificar que você não está enviando suas credenciais para um site de phishing. Somente um pode saber quantas contas de descobrir tem sido comprometidas porque cardholders foram condicionado ao provedor de seus nomes de usuário e senhas para qualquer pessoa que solicita.
Por outro lado, é impossível argumentar que o SSL foi um componente dos sistemas de identidade digital bem-sucedido. O fato de que ele permite que a autenticação do usuário é praticamente desconhecido, pelo menos para os usuários. O fato de que ele foi projetado principalmente para provar a identidade do servidor é ignorado por muitos provedores de serviço. Em vez disso, SSL é usado como um mecanismo de troca de chave caro e como uma fonte primária de receita para empresas que emitir os certificados que ninguém incomode inspecionar. Como atualmente implementado, SSL está falhando como um componente em sistemas de identidade digital. Ele não funciona com modelos de percepção do usuário e enquanto ele permite que provedores de serviços para se identificar, essa identificação é apresentada aos usuários finais tão mal que a maioria não entender como usá-lo.
Um sistema de identidade digital de ponta a ponta bem-sucedido deve fazer identificação de ambas as partes para a transação parte integral do fluxo de trabalho a autenticação. No entanto, um sistema de identidade digital deve primeiro e foremost soluciona o problema de identidade digital. Gerenciamento de identidades digitais, atualizando identidades digitais, armazenamento de identidades digitais, transmitir declarações provar identidades digitais, verificando identidades digitais e conceder acesso apropriado para identidades digitais são todos os problemas que são difíceis por conta própria. Se um sistema de identidade digital pode ser usado para solucionar outros problemas também, que é um bônus — mas ele não deve ser entre os objetivos de design do sistema.
Um exemplo perfeito é phishing. Phishing é um problema humano, não um digital-identity um. Seres humanos, não as tecnologias de ataques de phishing. Por fim, a única solução para phishing será ajudar as pessoas tomar decisões de segurança mais inteligentes. Um sistema de identidade certamente pode fazer isso, mas não às custas do objetivo principal como um sistema que é ajudam os usuários e serviço os provedores se identificam uns aos outros.

Permitir que o usuário para fornecer declarações com um nível de garantia adequado para o serviço fornecido
A maioria dos usuários usam muitos serviços de informações diferentes. Alguns serviços fornecem informações altamente confidenciais, como contas de contas bancárias ou economia de aposentadoria. Alguns fornecem informações que podem ser confidenciais em alguns casos, como email. Outros fornecem informações de valor a reputação de usuários, como sites de rede social. Ainda outros fornecem informações que não esteja em todos os confidenciais, como site de suporte técnico de um fornecedor de software.
Ainda assim, apesar dos diferentes níveis de sensibilidade envolvido com esses serviços, muitos tentar usar a mesma identidade. Por exemplo, a mesma identidade que usar para acessar meu email é solicitada sempre que tentar obter informações de produto a partir do meu fornecedor de software; se eu optar por fazer isso, eu poderia gerenciar minhas informações bancárias com a mesma identidade. Creio que meu email tem um valor significativo; minhas informações bancárias definitivamente faz. Informações de produto de software? Não muito. Porque facilmente, foi possível obter um vendedor para imprimir check-out e até mesmo unidade 30 milhas entregá-lo todos os, considero essas informações para praticamente não têm valor algum.
Esse tipo de uso sobrecarregado de credenciais é endemic aos sistemas de identidade. Ele é chamado "single sign-on." Em algumas maneiras, single sign-on é um conceito interessante. Em um ambiente empresarial, ele tem valor comercial grande e, se ainda não estiver disponível, ele deve ser adicionado à agenda agora. Fora da empresa, onde nós lidamos com informações de valor muito diferentes, single sign-on é perigoso. Se movimentado para seu newsstand e o vendedor solicitado duas formas de identidade antes de você foram permissão para comprar o papel da manhã, você certamente gostaria objeto, mas a mesma solicitação feita antes que você pode retirar $ 2.000 de sua conta bancária ou de unidade fora de um carro novo não aumentar seus sobrancelhas.
A mesma separação de declarações deve ter suporte um sistema de identidade digital bem-sucedido. Os usuários devem ser capazes de apresentar um conjunto de credenciais apropriados para o nível de risco representado pelos dados ou serviços que eles arerequesting.
Single sign-on não é em sistemas de identidade digital amplamente usados apropriado. É certamente aceitável usar single sign-on para acessar o próprio sistema, mas as credenciais reais apresentado para a terceira parte confiável — o provedor de serviços — deve ser proporcional com o serviço que o usuário está recebendo. Por esse motivo, é altamente provável, que, que formam um sistema de identidade digital bem-sucedido, ele oferecerá suporte a um sistema de identidade de duas camadas: uma camada para entrar no sistema de identidade digital próprio e outra para identificar, na verdade, o usuário a terceira parte confiável. Um sistema que fornece esse recurso bem é InfoCard sistema da Microsoft.
Melhor ainda, um bom sistema de identidade digital deve tornar fácil para o usuário enviar um conjunto de declarações definidas para um serviço para esse serviço, mas avisar o usuário ao enviá-las para outro serviço. Em outras palavras, o sistema de identidade digital deve ajudar os usuários a identificar os provedores de serviço que estão tentando acessar.

Focalizar a consistência de declarações em oposição a uma identidade canônico
Um sistema de identidade digital bem-sucedido deve respeitar a pessoa para a direita para privacidade. Embora a expectativa de privacidade exata bastante difere entre culturas, o desejo geral humano para privacidade, no entanto, ele é definido, é inquestionável. Você mesmo pode chamar uma necessidade humana inata de privacidade. Ele pode facilmente ser considerado uma necessidade de segurança, na hierarquia de Abraham Maslow das necessidades mostrado na Figura 1 . Maslow, escrita em pre-Internet vezes, pode simplesmente ter excluídos-lo como privacidade não quanto de um problema em 1943.
A Figura 1 hierarquia ’s Maslow de necessidades
Se nós aceitar privacidade como uma necessidade humana, ou pelo menos um desejo, pode discutir que precisam no contexto de um sistema de identidade digital. Considere, por exemplo, um sistema, como um quadro de discussão sobre seu hobby favorito. Como a maioria dos quadros de discussão exigem autenticação; em outras palavras, implementam um sistema de identidade digital. Que identidade você usa para esse quadro? Você usa seu nome real ou você ir um identificador de origem, como "Deep Diver 13"? A maioria de nós provavelmente usa algum tipo de apelido. Exigir que nós registrar um número de telefone válido e endereço residencial para esse fim deve provavelmente ser considerado uma violação de privacidade. Exigir que nós usar uma identidade digital que mapeia para nossa pessoa física e que também mapeia para nossos registros de integridade, certamente será considerado uma violação de privacidade.
Geralmente já disse que, para a maioria dos fins, sistemas de identidade digital precisam só se preocupar com um usuário pode estar consistente. Um usuário não precisa vincular um determinado sistema a identidade digital para uma identidade física ou mesmo para uma identidade digital usado em outro sistema. Os usuários não conseguirá ocultar suas identidades verdadeiras e ocultar links para outros sistemas, se no mesmo nível de sensibilidade ou outros, usando diferentes identidades digitais.
O sistema, em essência, deve concentrar na consistência de declarações apresentados pelo usuário, em vez de em ligação essas declarações para uma identidade canônica, normalmente ontological. Desde que o mesmo conjunto de declarações é apresentado, o usuário deve ser aceitas e para a maioria das finalidades, que é todo o sistema exige. Veja um site de varejo, por exemplo. O varejista realmente não precisa preocupar que um usuário, na verdade, é, a menos que as leis que regem a transação necessitam dele. O varejista precisa cuidado somente sobre se os usuários podem apresentar o mesmo consiste hoje como quando eles configurar suas contas e se seus métodos de pagamento ainda funcionam. Na maioria dos casos, que é suficiente para fazer uma transação bem-sucedida. Muitos sistemas de identidade overdo a parte "identidade" e tentarem vincular identidade a uma pessoa, ao contrário de um usuário.
Talvez ainda mais importante do que fornecer ao usuário a capacidade de proteger identidade ontological é a capacidade para facilitar a fabricar identidades. Um sistema de identidade digital é, afinal, apenas software. Muito facilmente ele pode ajudar usuários gerenciar identidades para maximizar a privacidade do usuário. Um sistema de identidade digital que implementa essa capacidade significa muito mais chances de sucesso daquele que ignora a ele.

Não misturar níveis de confiança
Um recurso interessante dos sistemas de identidade digital é que geralmente exigem uso de um provedor de identidade que difere do provedor de serviços. Se a confiança que o usuário coloca no provedor de serviço não coincidir com o nível de confiança colocado no provedor de identidade, há discord óbvia. Se o usuário confia o provedor de serviços, mas não o provedor de identidade que usa o provedor de serviços, o usuário pode ser relutante usar o provedor de serviço por esse motivo. Um exemplo interessante onde isso pode ocorrer é Anteriormente uma subsidiária, Expedia usa o Microsoft Passport, agora Windows Live ID, para autenticação, como mostrado na Figura 2 .
Figura 2 dá suporte a Expedia entrar com o Windows Live ID.
Agora vamos dizer que um usuário confia Expedia, mas não o Microsoft. Se Expedia necessário o uso do Windows Live ID (que não) que o usuário seria disposto a usar Expedia? Talvez. Talvez não. Que o caso esteja, o usuário é capaz de usar uma identidade Expedia em Expedia em oposição a um Windows Live ID um, e alguns usuários talvez prefira que.
Obviamente, o mesmo problema de confiança vai outra maneira. Se um usuário confia no Microsoft, mas não Expedia, o usuário talvez use Expedia se ele requer o uso de Windows Live ID. Talvez o usuário usou o Windows Live ID para fins altamente confidenciais, como proteger informações de conta bancária por meio do MSN Money. Nesse caso, alguns usuários podem ser relutantes usar o mesmo Windows Live ID que protege suas informações de conta bancária para as reservas de viagem de catálogo.
Esta propriedade de um sistema é muito parecido com o item anterior sobre a necessidade de declarações de acordo com a confidencialidade das informações que eles protegem. Em poucas palavras, o usuário deve confiar em determinadas partes em qualquer transação, mas a extensão para o qual essas partes são confiáveis pode ser diferentes. Mistura de confiança níveis é provável que forneça aos usuários motivos desconfiar o sistema.

Não violar leis ou regulamentos — ou expectativas
Alguns problemas no gerenciamento de informações de segurança hoje são tão irritante como conformidade legal e normativas. Enquanto muitos profissionais de segurança provavelmente não deseja pensar advogados como seus amigos melhores, advogados estão se tornando absolutamente necessários para a causa. Privacidade é uma questão de lei e regulamentação, e essas leis e normas diferem em jurisdições diferentes.
Isso gera um problema interessante. Digamos que um determinado sistema de identidade digital é recrutamento ativamente partes confiantes. As declarações de identidade obter pegou por uma terceira parte confiável que fornece informações que não seja muito confidenciais, como acesso a um fórum de discussão. A terceira parte confiável fornece um nível de segurança para as declarações de identidade proporcional com a confidencialidade das informações servem — em outras palavras, muito pouco. Agora digamos que o provedor de identidade assina um contrato com uma agência de relatório de crédito e conseqüentemente modifica o pacote de declarações para incluir um número de identificação nacional ou alguns representação dele. Essa nova declaração, de repente, é transmitida para o quadro de discussões. Protocolos de segurança do quadro de discussão não fornecem o nível de segurança necessário para essas informações, portanto, ele pode violar várias leis e regulamentações.
Esses problemas geralmente simples para solucionar e se os princípios restantes são seguidos, é improvável que esse ser violada, mas ainda é uma consideração importante. Da mesma forma, os sistemas de identidade digital que são usados em bordas nacionais devem ser confidenciais regras diferentes. Pedir a um determinado tipo de informações de identificação pode ser perfeitamente legítima em uma jurisdição; pedir o mesmo lugar de informações podem ser ilegal ou sujeito regulamentação.
Por exemplo, pedir age como parte de um sistema de identidade digital faz o provedor de identidade sujeitos a privacidade proteção ato de crianças nos EUA e leis semelhantes em outras jurisdições. Se um provedor de identidade disponibiliza essas informações para qualquer confiante não solicitá-lo, o requisito de conformidade é transferido para que parte confiante, mesmo que ele não queira que as informações. Obviamente, é fundamental que um sistema de identidade digital é capaz de respeitar esses tipos de leis e regulamentações e não colocar qualquer pessoa na violação.

Permitir que todos os atributos de voltados para o usuário a ser modificado ou excluído
Finalmente, um sistema de identidade digital deve colocar os usuários no controle de seus próprios dados. Isso é, talvez mais controversos de todos os princípios. Os provedores de identidade normalmente exiba as informações que coletar como dados comerciais. Os usuários, por outro lado, considere seus nomes, endereços e outras informações seu pessoal propriedade para usar como consulte ajustar, que pode incluir revogando alguém está certo para que ele.
Claramente, práticas atuais já rejeitar direitos de usuários para controlar completamente o acesso a suas informações; qualquer pessoa que tentou obter um dos três Estados Unidos agências de relatório de crédito para excluir informações pessoais podem ateste isso. Mesmo se essa informação está documentada como incorreta, agências relatórios de crédito são geralmente felizes manter vendê-lo. Precisão e a aprovação pela entidade dos dados é irrelevante. Discutir ethics de um sistema em que outra pessoa tem permissão para tirar proveito da suas informações de identificação sem seu consentimento está além do escopo deste artigo, mas para um sistema ser amplamente aceito por usuários, um sistema de identidade digital não deve colocar informações de usuários além do seu controle.
Isso significa que todas as informações devem ser modificadas, incluindo aspectos como nomes de usuário. Um tipo muito comum de nome de usuário é um endereço de email. Apesar do fato de que usando um endereço de email como um identificador pode violar alguns dos princípios separação discutidos anteriormente, ele também faz sentido usar um endereço de email como um identificador porque ele é garantidas como exclusivas. No entanto, também é uma entidade mutável e outra pessoa geralmente é concedida a um endereço de email usado anteriormente. Que significa que o sistema de identidade deve não permitir somente um usuário para modificar sua própria identificação de usuário se ele é um endereço de email, mas também que o sistema deve lidar com problemas que ocorrem quando novos usuários pegar endereços antigos. O que aconteceria se um novo usuário tentou o recurso de senha esquecida e recebeu acesso a informações da conta do outro usuário? Isso provavelmente não é ideal. Encerrar um endereço de email é um caso de uso perfeitamente válido. O sistema de identidade digital precisa lidar com esse contingência bem como com outras alterações nas informações, como nomes.

Claramente, sistemas de identidade digital são bem complicados. Não só são eles complicado para criar, como já sabíamos, mas os princípios precisam obedecer seja bem-sucedido amplamente são complexos de bem. Nós pode desenhar duas conclusões desta discussão. Sistemas de identidade digital, primeiro devem ser simplificados. Passamos vários anos tentando criar sistemas que funcionam em torno de usuários, não por meio de usuários. Sistemas de identidade digital devem fornecer os usuários com controle de suas informações sem fazer solicitações indevidas deles. No final extremo, eles devem oferecem suporte a usuários que desejam ser anônima. Da mesma forma, eles não devem exigir empresas para fazer mais sobre a implementação do sistema que o sistema que vale a pena.
Segundo, identidade digital sistemas devem fornecer identificação serviços que são apropriados à maneira como eles são usados. Eles devem fornecer para vários níveis de declarações para suportar o nível de garantia necessários para os sistemas que essas declarações estão sendo usadas para autenticar. Em outras palavras, na Internet como um todo, single sign-on provavelmente será apropriado apenas para o sistema usado para gerenciar identidades — ele não será a identidade propriamente dito.
Se nunca veremos uma única, sistema muito bem-sucedidas que atenda a todos esses princípios permanece para ser visto. A maioria das pessoas concorda que nós não ainda existe.

Jesper M. Johansson é o principal arquiteto de segurança para uma empresa Fortune 200 conhecida, trabalhando em segurança com base em risco visão e estratégia de segurança. Ele também é editor-colaborador da TechNet Magazine. Seu trabalho consiste em garantir a segurança em alguns dos sistemas maiores, mais distribuídos no mundo. Ele possui Ph.d. em sistemas de informações de gerenciamento, tem mais de 20 anos de experiência em segurança e é um Microsoft Most Valuable Professionals em segurança corporativa. Seu livro mais recente é Windows Server 2008 Security Resource Kit (Microsoft Press, 2008).

Page view tracker