{"id":9325,"date":"2020-09-10T08:38:59","date_gmt":"2020-09-10T15:38:59","guid":{"rendered":"https:\/\/www.couchbase.com\/blog\/?p=9325"},"modified":"2021-01-31T13:04:38","modified_gmt":"2021-01-31T21:04:38","slug":"authentication-using-server-side-x-509-certificates-with-n1ql","status":"publish","type":"post","link":"https:\/\/www.couchbase.com\/blog\/es\/authentication-using-server-side-x-509-certificates-with-n1ql\/","title":{"rendered":"Autenticaci\u00f3n mediante certificados X.509 del lado del servidor y N1QL"},"content":{"rendered":"

La autenticaci\u00f3n y autorizaci\u00f3n al servicio de consulta N1QL en Couchbase funciona de m\u00faltiples maneras -\u00a0<\/span><\/p>\n

    \n
  1. Pasar credenciales a trav\u00e9s de una petici\u00f3n rest - curl https:\/\/localhost:8093\/query\/service?pretty=true -d \"statement=select * from system:keyspaces\" -u Admin:pwd<\/span><\/li>\n
  2. Pasar credenciales utilizando el par\u00e1metro con nombre creds y\/o el par\u00e1metro de consulta -\u00a0<\/span>curl https:\/\/localhost:8093\/query\/service?pretty=true -d \"statement=select * from system:keyspaces&creds=[{user: \"Administrator\", \"password\": \"pass\"}]\"<\/li>\n
  3. Uso de autenticaci\u00f3n b\u00e1sica en la solicitud\u00a0<\/span><\/li>\n
  4. Solicitud de cbq (similar a 1,2) utilizando las opciones -u -p -creds y el comando \\SET.\u00a0<\/span><\/li>\n
  5. Certificados X.509 para TLS<\/span><\/li>\n
  6. Cifrado de nodo a nodo<\/li>\n<\/ol>\n

    Con la adici\u00f3n de RBAC, el par\u00e1metro de consulta creds se hizo redundante, pero todav\u00eda se admite por compatibilidad con versiones anteriores.<\/p>\n

    El objetivo de a\u00f1adir compatibilidad con certificados X509 es mejorar el cifrado cliente-servidor mediante un certificado en el que conf\u00ede la autoridad de certificaci\u00f3n.<\/p>\n

    Los certificados X.509 permiten la autenticaci\u00f3n del servidor y la encriptaci\u00f3n de las comunicaciones cliente-servidor. Couchbase soporta tanto autenticaci\u00f3n de servidor como de cliente usando certificados X509 y tienes que ser un Administrador completo o un Administrador de Seguridad para gestionar certificados. Este art\u00edculo habla sobre el soporte de certificados X.509 del lado del servidor para la autorizaci\u00f3n en Couchbase. Los clientes tambi\u00e9n pueden verificar la identidad del servidor de Couchbase, pero eso ser\u00e1 discutido en otro art\u00edculo.\u00a0<\/span><\/p>\n

    Los escenarios m\u00e1s comunes para los que se utilizan certificados X509 son cuando los clientes tienen que pasar por Internet, <\/span>cuando se transfieren datos confidenciales por cable entre la aplicaci\u00f3n y Couchbase Server, o entre centros de datos (XDCR) o cuando as\u00ed lo exigen las normativas de cumplimiento.\u00a0<\/span><\/p>\n

    \u00bfQu\u00e9 es un certificado X.509? <\/span><\/h2>\n

    Es un certificado de clave p\u00fablica que se utiliza para distribuir una clave p\u00fablica, firmada por una autoridad de certificaci\u00f3n de confianza que verifica la identidad del servidor. Utiliz\u00e1ndolo, un cliente se asegura de que la solicitud no se est\u00e1 enviando a un servidor desconocido. Estos certificados est\u00e1n firmados por un tercero, tambi\u00e9n conocido como autoridad de certificaci\u00f3n. <\/span>Las CA son entidades que emiten certificados digitales. En realidad, una CA est\u00e1 formada por una serie de CA denominadas jerarqu\u00eda de CA. Esta jerarqu\u00eda de CA construye una cadena de confianza en la que se basan todos los certificados de nodos o entidades finales. La cadena no contiene la clave p\u00fablica de la CA ra\u00edz.\u00a0<\/span><\/p>\n

    En una infraestructura jer\u00e1rquica de clave p\u00fablica (PKI) suele haber 3 tipos de jerarqu\u00eda. De un nivel, de dos niveles y de N niveles. La CA situada en la parte superior de la jerarqu\u00eda se denomina CA ra\u00edz. Todas las CA siguientes son CA intermedias, y la en\u00e9sima (\u00faltima) se denomina CA de nodo.\u00a0<\/span><\/p>\n

    Un punto importante a tener en cuenta es <\/span>que para confiar en un certificado utilizado para establecer una conexi\u00f3n segura debe haber sido emitido por una CA que est\u00e9 incluida en el almac\u00e9n de confianza del dispositivo que se est\u00e1 conectando.<\/span><\/p>\n

    Autoridad de certificaci\u00f3n de un solo nivel <\/b><\/h3>\n

    Consiste en una \u00fanica CA es la forma m\u00e1s sencilla de jerarqu\u00eda de CA, pero no suele utilizarse en producci\u00f3n como una<\/span> Si se compromete esta CA ra\u00edz, se compromete toda la PKI. <\/span>Aqu\u00ed la CA ra\u00edz es tambi\u00e9n la CA emisora y <\/span>todos los certificados inmediatamente inferiores al certificado ra\u00edz heredan su fiabilidad.<\/span><\/p>\n

    \"\"<\/p>\n

    Autoridad CA de dos niveles<\/b>\u00a0<\/span><\/h3>\n

    Consiste en una CA Ra\u00edz que ha emitido un certificado para una subordinada conocida como CA Intermedia. La diferencia es que los certificados emitidos son de confianza, ya que proceden de una autoridad de confianza a trav\u00e9s de la CA intermedia.\u00a0<\/span><\/p>\n

    \"\"<\/p>\n

    Signos de CA ra\u00edz-><\/span> Signos intermedios de CA<\/span> -> CA emisora \/ CA de cl\u00faster<\/span><\/p>\n

    Autoridad CA N-Tier <\/b><\/h3>\n

    \u00a0En la mayor\u00eda de los despliegues de producci\u00f3n, una jerarqu\u00eda tiene varias CA.<\/span> La CA ra\u00edz emite certificados a las CA intermedias, que a su vez generan <\/span>certificados intermedios<\/span><\/i>: se utilizan para firmar certificados de cliente, como un certificado de cl\u00faster:<\/span><\/p>\n