Sugerir traducción
 
Otros han sugerido:

progress indicator
No hay más sugerencias.
TechNet Magazine > Inicio > Todos los números > 2009 > TechNet Magazine Julio 2009 >  Vigilancia de seguridad: Comentarios de identid...
Ver contenido: en paraleloVer contenido: en paralelo
La información aquí ofrecida es contenido traducido automáticamente que los miembros de la comunidad pueden editar. Quienes deseen contribuir a mejorar la traducción, pueden hacer clic en el vínculo “editar” asociado a cualquiera de los siguientes enunciados.
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 Expedia.com. 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.

Summary
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).

Vigilancia de seguridad Ideas sobre la identidad, parte 2
Jesper M. Johansson


El mes pasado, embarked en la tarea algo desalentadora de descripción de los sistemas de identidad y, en concreto, por qué se sigue don’t tienen una industria uno estándar. En primer lugar, se defi ned qué identidad es realmente y por qué nos importa identidades en sistemas digitales. A continuación, tratan los problemas con la identidad, especialmente, el hecho de que todos tenemos no sólo una identidad, pero muchos. A continuación, señalar que si no crees que tienes suficientes, puede siempre crear o comprar unos más.
Como se explicó, esto crea un problema en la autenticación porque pensamos normalmente de identidad como una identidad ontological: una representación de una persona real, física. En la mayoría de los sistemas, esa relación resulta para ser una complicación innecesaria. La mayoría de las identidades no necesita ser representativos de la entidad real que identifican o incluso identifican cualquier entidad del mundo real en absoluto, de hecho, es a menudo no deseado para poder hacerlo.
Por último, trata cómo funciona la autenticación, en concreto, que realmente interesante sucede en el sistema de socio técnico donde el consumidor de algún servicio proporciona la prueba de identidad. He indicado que un sistema de identidad digital correcto debe satisfacer determinados criterios y se ajustan a un conjunto de principios básicos. En la parte I, tratan los dos primeros principios tales: "el proveedor de identidad es al menos como confidencial como la parte más sensible confiar" y "permitir la empresa para proteger sus relaciones de cliente y para el propietario y controlar información que estime como negocio confidencial." Aquí, en la parte II, concluir la serie por cobertura adicionales principios que deben cumplir los sistemas de identidad digital correcta.

Ser independiente de plataforma
Ya que son de empresa para que money, las empresas se satisfacer a sus clientes. Tendrá centrar sus esfuerzos reducir la cantidad de "Fricción" necesario para que el cliente de lado a través de sus dólares duro acumulado. Cualquier empresa inteligente evita los requisitos de sus clientes que reducen la probabilidad del cliente de mantener a un cliente, ni ningún requisito que reduce la base de clientes. Que significa que no empresariales convencionales utilizará una solución de identidad que excluye varios de sus clientes puedan gastar dinero en la empresa. Asimismo, no racional empresariales se va a implementar una solución de identidad requiere sus clientes ir a longitudes adicionales desea instalar software nuevo o los componentes para poder utilizarlo.
Una decisión de implementación similar se realizarán para una solución de identidad que funciona para sólo un subconjunto de los clientes. Supongamos que una solución costos 5 millones de dólares a implementar. También suponga que el efectivo libre flujo de la empresa, la proporción de sus ingresos que no se marcadas para cualquier proyecto de desarrollo actual, es por ciento de 7 de sus ingresos brutos. En este caso, la empresa tendría que generar un adicionales 71.5 millones en ingresos de la solución sólo para cubrir el costo de implementación. Que es un número considerable, especialmente si proporciona sólo una solución mejorada de forma incremental para un subconjunto de los clientes. Hay tendría que ser un impacto para la seguridad de los clientes para justificar measureable. Algunos, si hay alguna, soluciones de identidad cumpliría estos requisitos.

Trabajar bien con Framework Cognoscitivo del usuario
En última instancia, un sistema de identidad personas uso debe trabajar dentro del marco cognitivas humano. Puede parecer sorprendente tal, los seres humanos no evolucionar para tratar con sistemas de identidades digitales. Ni podría parecer inteligente especialmente diseñadas para ello. Muchos scholars en ciencia cognitiva afirman que el cableado fundamental de los seres humanos fue diseñado para tratar con la vida en Cueva, foraging para comida (y compañeros) e intentar sobrevivir a los ataques por gatos dentada especialistas. Sin duda, humanidad ha dedicado cotidianos mucho más en cuevas que en cubículos y mucho más comunicarse humo señales que electrons. En la vida de cueva, teníamos poco uso de identidades digitales y, por lo tanto, nos no evolucionar con cableado dirigido específicamente para comprenderlos.
Por tanto, nuestro modelo mental del mundo no incluye administrar cientos de identidades digitales para proteger las transacciones electrónicas. Sin embargo, es perfectamente razonable suponer que las personas tenían que utilizar código palabras mientras viven en cuevas. Ciertas palabras que es probable que tenían un significado especial y obtuvo resultados especiales. " Por favor,"probablemente tenía algún tipo de precursor de hablar de caveman, sólo uno.
No estoy diciendo que el uso palabras de código o el equivalente actual, las contraseñas, es la forma razonable sólo para autenticar una identidad digital. Digo que si una mayoría de los usuarios se acepte el sistema de identidad digital, debe no requiere que cambien su modelo cognitivas del mundo. Modelos cognitivas son en gran medida cableados. Sin duda se puede tratar con sistemas que no caben con modelos cognitivas, pero hacerlo así tiene un costo: Ira, frustración y esfuerzo. Con tal un sistema tendría que incluir una ventaja que supera el costo de esos factores. Por el contrario, un sistema intuitivamente obvio recibirá mayores niveles de adopción incluso si proporciona menos otras ventajas.

Garantía de identificación bidireccional
Entre los aspectos más importantes de un sistema de identidad digital y que, Desgraciadamente, no comprenden bien los usuarios de estos sistemas, es la identificación de la fiesta confiar o el proveedor de identidades a los usuarios finales. La entidad que confía, o más, el proveedor de servicio, los usuarios finales es de confianza a menudo implícitamente. Por eso los ataques de suplantación de identidad, es decir, robar una identidad haciéndose pasar por una entidad de confianza, son tan increíblemente correctas. No tiene mucho para engañar a un número suficiente de usuarios para mostrar sus secretos.
Un sistema de identidad digital correcto debe permitir todas las partes para autenticarse en formas que ajustan el modelo cognitivas de usuario del sistema. Por desgracia, los proveedores de servicios a menudo omiten este aspecto crucial del sistema. En mi serie "seguridad es acerca de contraseñas y la tarjetas de crédito", ilustra cómo una compañía de tarjeta de crédito popular rechaza activamente para identificarse a usted antes de autenticar a él. Al escribir este artículo no ofrece me placer informe que descubra rechaza mostrar una identidad digital de un usuario antes de pedir al usuario para autenticar. Si ir al sitio Descubra Web ficha, le se redirige y le solicitará su nombre de usuario y contraseña sin cualquier oportunidad para comprobar que no envían sus credenciales a un sitio de suplantación de identidad. Sólo uno puede saber cuántas cuentas de descubrimiento se han comprometido porque han cardholders preparan al proveedor de sus nombres de usuario y contraseñas a cualquier persona que le pide.
Por otro lado, es imposible argumentar que SSL ha sido un componente correcto de sistemas de identidad digital. El hecho de que permite autenticación de usuario es prácticamente desconocido, al menos a los usuarios. Muchos proveedores de servicios omite el hecho de que está diseñado principalmente para demostrar la identidad del servidor. En su lugar, SSL se utiliza como mecanismo de intercambio de claves caro y como origen principal de ingresos a compañías que emiten los certificados que nadie molesta a inspeccionar. Como está implementado, actualmente falla SSL como un componente en sistemas de identidad digital. No funciona con modelos cognitivas del usuario y mientras permite identificarse los proveedores de servicio, esta identificación se presenta a los usuarios finales mal que la mayoría no sepan cómo utilizarlo.
Un sistema de identidad digital de extremo a extremo correcto debe realizar identificación de ambas partes en la transacción una parte integral de flujo de trabajo de autenticación. No obstante, un sistema de identidad digital debe en primer lugar y principalmente resolverá el identidad digital problema. Administrar identidades digitales, actualizar identidades digitales, almacenar identidades digitales, transmitir solicitudes demostrando identidades digitales, comprobar las identidades digitales y conceder acceso apropiado a identidades digitales son todos los problemas que son difíciles solos. Si un sistema de identidad digital puede utilizarse para resolver otros problemas así, es una bonificación, pero no debería ser entre los objetivos de diseño del sistema.
Un ejemplo perfecto es la suplantación de identidad. Suplantación de identidad es un problema humano, no un digital identidad uno. Los seres humanos, no las tecnologías de ataques de phishing. Finalmente, la única solución para la suplantación de identidad será ayudan a las personas tomar decisiones de seguridad más inteligentes. Un sistema de identidad sin duda puede hacerlo, pero no a costa del propósito principal de dicho sistema que ayuda a los usuarios y servicio proveedores identifican entre sí.

Permitir que el usuario para proporcionar notificaciones con un nivel de control apropiado al servicio proporcionado
La mayoría de los usuarios utilizan muchos servicios de información diferente. Algunos servicios proporcionan información muy confidencial, como cuentas de ahorros de jubilación o de cuentas bancarias. Algunos proporcionan información que puede ser sensible en algunos casos, como el correo electrónico. Otras proporcionan información del valor a la reputación de los usuarios, como sitios de red social. Todavía otros proporcionan información que no entre mayúsculas y en minúsculas, como sitio de soporte técnico del proveedor de software.
Aún, a pesar de los diferentes niveles de sensibilidad implica con estos servicios, muchos intente utilizar la misma identidad. Por ejemplo, se solicita la misma identidad que utilizo para tener acceso a mi correo electrónico cada vez que se intenta obtener información de producto de mi proveedor de software; si se decide hacerlo, podría administrar mi información de banca con la misma identidad. Creo que mi correo electrónico tiene un valor significativo; mi información de banca definitivamente. ¿Información de producto de software? No mucho. Dado que fácilmente podría llegar a un vendedor para imprimir lo y unidad incluso de 30 millas para entregar todo, considero esa información a no tener prácticamente ningún valor.
Este tipo de uso sobrecargado de credenciales es endemic a sistemas de identidad. Se llama "único inicio de sesión en." En algunos sentidos, inicio de sesión único es un concepto atractivo. En un entorno empresarial, tiene empresarial gran valor y, si ya no está disponible, debe agregarse a la agenda ahora. Fuera de la empresa, donde se tratan con información de valor muy dispar, inicio de sesión único es peligroso. Si recorre una de su newsstand y el vendedor pedido de dos formas de identidad antes de que se le permita comprar papel por la mañana, debería seguramente objeto, pero la misma solicitud antes de que puede retirar $ 2.000 de su cuenta bancaria o unidad fuera de un automóvil nuevo no provoca las eyebrows.
Debe admitir la misma separación de las reclamaciones por un sistema digital identidad correcto. Los usuarios debe ser capaces de presentar un conjunto de credenciales adecuados para el nivel de riesgo representado por los datos o servicios arerequesting.
Inicio de sesión único es inadecuada en sistemas de identidad digital ampliamente utilizados. Es ciertamente es aceptable utilizar inicio de sesión único para tener acceso el propio sistema, pero las credenciales reales presentan a la parte que confía, el proveedor de servicios, debe ser acorde con el servicio recibe el usuario. Por ese motivo, es muy probable que lo forman un sistema digital identidad correcto toma, admitirá un sistema de identidad de nivel dos: una capa de iniciar sesión en el sistema de identidad digital propio y otro para identificar realmente al usuario a la entidad confiar. Un sistema que proporciona esta utilidad perfectamente es sistema InfoCard de Microsoft.
Mejor aún, un buen sistema de identidad digital debe hacer fácil que el usuario enviar un conjunto de solicitudes definido para un servicio para ese servicio, pero advertir al usuario cuando se envía a otro servicio. En otras palabras, el sistema de identidad digital debe ayudar a identificar los proveedores de servicio que están intentando obtener acceso de usuarios.

Centrarse en la coherencia de notificaciones en oposición a una identidad canónico
Un sistema de identidad digital correcto debe respetar a la persona de derecha a privacidad. Aunque la intención exacta de privacidad difiere considerablemente entre referencias culturales, el general humano deseo de privacidad, sin embargo, se define, es imprescindible. Incluso puede llamar a una necesidad humana innatas de privacidad. Fácilmente se pueden considerar una necesidad de seguridad, bajo jerarquía de Abraham Maslow de necesidades que se muestra en la figura 1 . Maslow, escribir en pre-Internet veces, puede simplemente ha excluidos, porque privacidad no como parte de un problema en 1943.
Figura 1 jerarquía ’s Maslow de necesidades
Si se acepta privacidad como una necesidad humana o al menos un deseo, trataremos que necesitan en el contexto de un sistema de identidad digital. Considere, por ejemplo, un sistema como un panel de discusión sobre tu afición favorita. La mayoría de los estos paneles de discusión requieren autenticación; en otras palabras, implementan un sistema de identidad digital. ¿Qué identidad utiliza para ese panel? ¿Utiliza su nombre real o vaya por un moniker, como "Deep Diver 13"? La mayoría de nosotros probablemente utilizará algún tipo de alias. Requerir nos registrar un número de teléfono válido y una dirección principal para este fin probablemente se consideraría una infracción de privacidad. Requerir nos utilizar una identidad digital que se asigna a nuestro persona física y que también se asigna a nuestros registros de estado, seguramente se va a considerarse una infracción de privacidad.
A menudo ha dicho que, en la mayoría de los casos, sistemas de identidad digital necesitan sólo que preocuparse de si un usuario puede estar constantemente. Un usuario no tiene que enlazar identidad digital de un sistema determinado a una identidad física o incluso a una identidad digital utilizada en otro sistema. Los usuarios podrán ocultar sus identidades true y ocultar vínculos a otros sistemas, si se encuentra en el mismo nivel de sensibilidad o otros distintos, utilizando diferentes identidades digitales.
El sistema, en esencia, debe centrarse en la coherencia de las solicitudes presentadas por el usuario, en lugar de en esas solicitudes a una identidad canónica, normalmente ontological de enlace. Siempre y cuando se presenta el mismo conjunto de notificaciones, debe aceptarse el usuario y la mayoría de los casos, esto es todo el sistema requiere. Tomemos un sitio Web comercial, por ejemplo. El distribuidor realmente no es necesario preocuparse que un usuario realmente es, a menos que lo requieren las leyes que rigen la transacción. El distribuidor debe ocupa aproximadamente sólo si los usuarios pueden presentar los mismos archivos hoy como cuando configura sus cuentas y si siguen funcionan sus métodos de pago. En la mayoría de los casos, que es suficiente para realizar una transacción correcta. Muchos sistemas de identidad overdo la parte "identidad" e intenten vincular de identidad para una persona, en oposición a un usuario.
Incluso más importante que proporcionar al usuario la capacidad de proteger su identidad ontological es la capacidad de para facilitar la fabrica identidades. Después de todo, un sistema de identidad digital es sólo software. Muy fácilmente puede ayudar a los usuarios administrar identidades para maximizar la privacidad del usuario. Un sistema de identidad digital que implementa esta capacidad significa mucho más posibilidades de éxito que uno que se omite.

No mezcle niveles de confianza
Una característica interesante de los sistemas de identidad digital es que requieren a menudo el uso de un proveedor de identidades difiere el proveedor de servicios. Si la confianza que el usuario coloca en el proveedor de servicios no coincide con el nivel de confianza que se coloca en el proveedor de identidades, es obvio discord. Si el usuario confía el proveedor de servicio, pero no el proveedor de identidades que utiliza el proveedor de servicios, el usuario puede ser reacios a utilizar el proveedor de servicios por ese motivo muy. Un ejemplo interesante que esto puede ocurrir es Expedia.com. Anteriormente una subsidiaria de Microsoft Expedia utiliza Microsoft Passport, ahora Windows Live ID, para la autenticación, como se muestra en la figura 2 .
Figura 2 admite Expedia inicio de sesión en con Windows Live ID.
Ahora supongamos que un usuario confía Expedia, pero no Microsoft. ¿Si Expedia requiere el uso de Windows Live ID (que no es así) que el usuario sería dispuesto a utilizar Expedia en absoluto? Quizá. Quizá no. Lo que puede ser el caso, el usuario puede utilizar una identidad de Expedia de Expedia en oposición a un Windows Live ID uno, y algunos usuarios que prefiera.
Por supuesto, el mismo problema de confianza pasa la otra forma. Si un usuario confía Microsoft pero no de Expedia, el usuario puede ser no puede utilizar Expedia si requiere el uso de Windows Live ID. Quizás el usuario ha utilizado Windows Live ID fines muy confidencial, como proteger información de cuenta bancaria a través de MSN Money. En ese caso, algunos usuarios quizás reacios utilizar el mismo Windows Live ID que protege su información de cuenta bancaria para las reservas de viajes de libro.
Esta propiedad de un sistema es muy parecido en línea con el elemento anterior acerca de requerir reclamaciones de acuerdo con la confidencialidad de la información que protegen. En pocas palabras, el usuario debe confiar en determinadas partes de cualquier transacción, pero puede variar el alcance para que esas entidades son de confianza. Mezcla de niveles es probable que proporcionar razones para desconfiar del sistema a los usuarios de confianza.

No infringen leyes o normas, o las expectativas
Hoy en día algunos problemas de administración de seguridad de la información son como vexing como cumplimiento legal y las disposiciones legales. Mientras muchos profesionales de seguridad probablemente no desea considerar abogados como sus mejores amigos, abogados se están convirtiendo en absolutamente necesarios para la causa. Privacidad es una cuestión de legislación y normativa, y esos legislación y normativa difieren en distintas jurisdicciones.
Esto provoca un problema interesante. Supongamos que un determinado sistema identidad digital activamente es contratación partes confiar. Las notificaciones de identidad obtener recogidas por otro usuario de confianza que proporciona información que no es muy sensible, como el acceso a un foro de discusión. La entidad confiar proporciona un nivel de seguridad para la proporción con la confidencialidad de la información de reclamaciones de identidad sirven, en otras palabras, muy poco. Ahora supongamos que el proveedor de identidades firma un contrato con una agencia de informes de crédito y, por lo tanto, modifica el paquete de reclamaciones al incluir un número de identificación nacional o alguna representación de ella. Esta notificación nueva pronto se transmite en el panel de discusión. Protocolos de seguridad del panel de discusión no proporcionan el nivel de seguridad necesario para dicha información, por lo que puede infringir distintas leyes y regulaciones.
Estos son los problemas sencillos normalmente para evitar y si se siguen los principios restantes, es poco probable que éste se ha infringido, pero todavía es una consideración importante. Del mismo modo, los sistemas de identidad digital que se utilizan a través de bordes nacionales deben ser sensibles a reglas diferentes. Pide una parte determinada de información de identificación puede ser perfectamente legítimo en una jurisdicción; pedir el mismo puede ser información en otro lugar no válido o sujetos a la normativa.
Por ejemplo, pedir antigüedad como parte de un sistema de identidad digital permite que el identidad proveedor sujeto a la ley de protección privacidad en línea de los niños en los Estados Unidos y en las leyes similares en otras jurisdicciones. Si un proveedor de identidades hace que esa información esté disponible a cualquier parte confiar que no lo solicita, el requisito de cumplimiento se transfiere a esa parte confiar incluso si no desea la información. Obviamente, es muy importante que un sistema de identidad digital es capaz de respetar los tipos de las leyes y normativas y no cualquiera de infracción.

Permitir todos los atributos de cara al usuario para ser modificados o eliminados
Por último, un sistema de identidad digital debe colocar los usuarios en control de sus propios datos. Esto es quizás el más controvertido de todos los principios. Los proveedores de identidad suelen ver la información que recopilan como datos empresariales. Los usuarios, por el contrario, considere sus nombres, direcciones y otra información de su personal propiedad utilizar como convenga, que podría incluir revocar alguien del derecho que.
Claramente, prácticas recomendadas actuales rechazar ya derechos de usuarios para controlar completamente el acceso a su información; cualquier persona que ha intentado obtener uno de los tres Estados Unidos Esto pueden atestiguan agencias de informes de crédito para eliminar información personal. Incluso si esa información se documenta como incorrecto, las agencias de informes de crédito son normalmente felices mantener a vender. Precisión y la aprobación por el asunto de los datos es irrelevante. Explicar la ética de un sistema donde alguien se le permite beneficiarse de la información de identificación sin su consentimiento está fuera del alcance de este artículo, pero para que ser ampliamente aceptados por los usuarios un sistema, un sistema de identidad digital no debe incluir información de los usuarios más allá de su control.
Esto significa que toda la información debe ser modificable, incluyendo aspectos como nombres de usuario. Un tipo muy común de nombre de usuario es una dirección de correo electrónico. A pesar del hecho de que el uso de una dirección de correo electrónico como un identificador puede infringir algunos de los principios de separación que se explicó anteriormente, también tiene sentido utilizar una dirección de correo electrónico como un identificador porque se garantiza que ser únicos. Sin embargo, también es una entidad mutable y otra persona a menudo se concede una dirección de correo electrónico utilizado anteriormente. Que significa que el sistema de identidad no debe permitir sólo un usuario para modificar su identificador de usuario si es una dirección de correo electrónico, sino también que el sistema debe tratar con problemas producidos cuando nuevos usuarios recoger direcciones antiguas. ¿Qué sucedería si un nuevo usuario intentó la característica de contraseña olvidado y recibido acceso a información de cuenta otro usuario? Probablemente no es óptima. Retiro de una dirección de correo electrónico es un caso de uso perfectamente válido. El sistema de identidad digital necesita tratar con este contingencia, así como con otros cambios de información, como nombres.

Resumen
Claramente, sistemas de identidad digital son bastante complicados. No sólo son que complicado para generar, como ya sabíamos, pero los principios que necesitan para cumplir con tenga éxito ampliamente son complejas así. Se pueden dibujar dos conclusiones de este debate. Sistemas de identidad digital, primero deben ser simplificados. Hemos pasado años intentando diseñar sistemas que evitar a los usuarios, no a través de los usuarios. Sistemas de identidad digital deben proporcionar a los usuarios con control de su información sin realizar solicitudes indebidas de ellos. Al final de extremo, deben admitir los usuarios que desean ser anónimo. Del mismo modo, no debe requieren las empresas a hacer más en la implementación del sistema que el sistema merece la pena.
Sistemas de segundo, la identidad digital deben proporcionar servicios de identificación que son adecuados para la forma en que se utilizan. Debe proporcionar para varios niveles de notificaciones para admitir el nivel de seguridad necesitan para los sistemas que las solicitudes se utilizan para autenticar. En otras palabras, en Internet como un todo, inicio de sesión único en probablemente será apropiado sólo para el sistema utilizado para administrar identidades, no será la identidad.
Si alguna vez veremos una sola, sistema mucho éxito que cumpla todos estos principios permanece a verse. La mayoría de las personas de acuerdo que nos no aún existe.

Jesper M. Johansson es arquitecto de seguridad principal para una empresa Fortune 200 conocida, trabajando en la seguridad basada en riesgos visión y estrategia de seguridad. También es colabora como editor de TechNet Magazine. Su trabajo consiste en garantizar la seguridad en algunos de los sistemas más grandes, más distribuidos en el mundo. Contiene un Dr. en sistemas de información de administración, tiene más de 20 años de experiencia en seguridad y es un profesionales más valiosos de Microsoft en seguridad empresarial. Su último libro es el Windows Server 2008 Security Resource Kit (Microsoft Press, 2008).

TechNet Features

Resources

TechNet Subscriptions

¿No es suscriptor de TechNet?

Conviértase en suscriptor hoy y obtenga acceso oportuno a miles de productos de Microsoft como:

      
Page view tracker