SPS

Categorías
Zero Trust

LAOUC Community Tour 2024: El evento de conocimiento de Tecnología Oracle, impulsado por la Comunidad del Grupo de Usuarios: ORAMEX

LAOUC Community Tour 2024: El evento de conocimiento de tecnología Oracle, impulsado por la Comunidad del Grupo de Usuarios: ORAMEX

¿Habías escuchando hablar del LAOUC Community Tour?

Este viernes 02 de agosto se llevará a cabo la edición 2024 del LAOUC Community Tour, en el Anexo de la Facultad de Ingeniería de la Universidad Nacional Autónoma de México.

 

LAOUC Community Tour 2024

Durante este evento, se ofrecerán conferencias en aulas del centro de cómputo, y se cuenta con una agenda clasificada en 4 ejes principales:  APEX, ORACLE DATABASE, CLOUD DEVELOPMENT, DIFFERENT TOPICS.

 

Agenda LAOUC Community Tour 2024

Agenda del LAOUC Community Tour 2024

LAOUC Community Tour es un evento para entusiastas y usuarios de la tecnología ORACLE

Si eres un entusiasta de la tecnología ORACLE, o en tu compañía trabajan con alguna de sus tecnologías y quieres ampliar tu dominio o conocimiento, definitivamente asistir a este evento te permitirá explorar casos de uso, o estrategias basadas en las experiencias de los presentadores. 

13_ORAMEX

Durante años anteriores, este evento ha reunido a más de 300 personas el mismo día. El año pasado, el equipo de ORAMEX, tuvo la oportunidad de realizar este evento en el ORACLE MDC (Centro de Desarrollo de Soluciones en la Nube de Oracle), ubicado en Guadalajara, Jalisco, y fue todo un éxito debido a que tuvimos asistentes de diferentes partes del mundo. Todos con la misma finalidad: ampliar sus conocimientos sobre tecnología ORACLE.

ORACLE MDC

ORACLE MDC, Guadalajara, Jalisco

Además de obtener conocimiento, el LAOUC te permite crear conexiones con otros especialistas en tecnología, por lo que es una gran oportunidad para realizar networking, incluso generar oportunidades de negocio. 

LAOUC Community Tour en ORACLE MDC Guadalajara, Jalisco
LAOUC Community Tour en ORACLE MDC Guadalajara, Jalisco
LAOUC Community Tour en ORACLE MDC Guadalajara, Jalisco
LAOUC Community Tour en ORACLE MDC Guadalajara, Jalisco
LAOUC Community Tour en ORACLE MDC Guadalajara, Jalisco
03_ORAMEX

¡Anímate a ser parte del LAOUC Community Tour 2024!

Asiste junto con tus compañeros de equipo, de la universidad o clientes. Sólo debes registrarte:

Si ya te has registrado, y has calendarizado tu asistencia, te compartimos este vídeo, que te será de ayuda para que puedas llegar sin contratiempos al Anexo de la Facultad de Ingeniería de la UNAM.

¡Te esperamos este 2 de agosto a partir de las 8:00 am! 

Categorías
Zero Trust

¿Qué es el Zero Trust Network?

¿Qué es el Zero Trust Network?

¿A qué nos referimos con la «Cero Confianza»?

El Zero Trust Networking (ZTN) es un enfoque de seguridad de redes basado en el principio de que ninguna entidad, ya sea interna o externa a la red, debe ser confiable por defecto. En lugar de asumir que todo dentro del perímetro de la red es seguro, el modelo Zero Trust requiere la verificación constante de todos los usuarios y dispositivos que intentan acceder a los recursos de la red. Este enfoque se opone al modelo tradicional de seguridad, que se basa en proteger el perímetro de la red y confiar implícitamente en todo lo que está dentro.

John Kindervag, senior vice president, cybersecurity strategy, ON2IT Cybersecurity

¿Cómo el Zero Trust Network ayuda a la seguridad de los procesos empresariales?

El Zero Trust Networking mejora la seguridad de los procesos empresariales de varias maneras:

Reducción de la superficie de ataque: Al segmentar la red y aplicar controles de acceso estrictos, ZTN minimiza las oportunidades para que los atacantes se muevan lateralmente dentro de la red. Cada segmento de la red está aislado, y el acceso a cada segmento se controla de manera independiente.

Autenticación y autorización continuas: En lugar de autenticar a los usuarios solo en el punto de entrada, ZTN requiere autenticación continua en cada acceso a recursos críticos. Esto asegura que solo los usuarios y dispositivos autorizados puedan acceder a la información sensible.

Protección contra amenazas internas: Las amenazas internas, ya sean maliciosas o accidentales, son una preocupación significativa para las empresas. ZTN mitiga este riesgo al no confiar implícitamente en ninguna entidad dentro de la red y al monitorear continuamente las actividades sospechosas.

Mejora de la visibilidad y el control: Al implementar políticas de Zero Trust, las empresas obtienen una mayor visibilidad sobre quién accede a qué recursos y cuándo. Esto permite una detección más rápida de actividades anómalas y una respuesta más efectiva a incidentes de seguridad.

Adaptabilidad a entornos cambiantes: Con el aumento del trabajo remoto y el uso de dispositivos personales (BYOD), ZTN proporciona un marco flexible que puede adaptarse a estos cambios. La autenticación y la autorización basadas en el contexto permiten a las empresas mantener la seguridad incluso cuando los empleados acceden a la red desde ubicaciones y dispositivos no tradicionales.

ciberseguridad procesos de empresa con zero trust

¿En qué partes del mundo ya se utiliza el Zero Trust Network como enfoque de seguridad?

El Zero Trust Network ha ganado popularidad a nivel mundial y ha sido adoptado en diversas regiones, incluyendo América del Norte, Europa y Asia-Pacífico. A continuación, se describen algunas de las áreas donde se ha implementado con éxito:

 

Estados Unidos: Como el lugar de origen del concepto de Zero Trust, Estados Unidos ha visto una amplia adopción en sectores como el gobierno, la tecnología y la salud. En 2021, el gobierno de EE. UU. emitió una orden ejecutiva que exige a las agencias federales adoptar principios de Zero Trust para mejorar la ciberseguridad nacional.

 

Europa: En Europa, el Zero Trust se ha convertido en una estrategia clave para cumplir con regulaciones como el Reglamento General de Protección de Datos (GDPR). Países como el Reino Unido, Alemania y Francia han adoptado políticas de Zero Trust en sectores críticos para proteger los datos sensibles y cumplir con las normativas de privacidad.

 

Latinoamérica: Aunque la adopción del Zero Trust en Latinoamérica ha sido más lenta en comparación con otras regiones, países como Brasil, México y Argentina están comenzando a implementar estos principios en sectores clave como la banca y las telecomunicaciones.

Mark Ryland, director de la Oficina del CISO de AWS, y Abby Daniels, gerente de Sector Público de AWS para América Latina. Foto EE: Rodrigo Riquelme

¿Qué empresas u organizaciones han adoptado estrategias de seguridad basadas en Zero Trust Network?

Tech support in data center uses laptop to prevent system overload during peak traffic periods. Hardworking expert in server farm ensuring enough network bandwidth for smooth operations, close up

Muchas empresas y organizaciones líderes en sus respectivas industrias han adoptado estrategias de Zero Trust Network para proteger sus redes y datos. Algunos ejemplos notables incluyen:

Google: Google fue uno de los pioneros en adoptar el enfoque de Zero Trust con su proyecto «BeyondCorp». Esta iniciativa permitió a los empleados acceder a recursos corporativos desde cualquier lugar sin necesidad de una VPN tradicional, basándose en la autenticación y autorización continuas.

Microsoft: Microsoft ha integrado principios de Zero Trust en sus productos y servicios, promoviendo su adopción entre sus clientes. La compañía lo ha implementado en su propia infraestructura para mejorar la seguridad y proteger los datos de los clientes.

CISCO usa el enfoque de seguridad zero trust

Cisco: Cisco ofrece soluciones de Zero Trust a través de su plataforma Cisco Secure, que incluye herramientas para la autenticación multifactor, la segmentación de red y la visibilidad de las amenazas. La empresa ha adoptado estos principios internamente para asegurar su propia red.

IBM empresa que utiliza el enfoque de seguridad zero trust

IBM: IBM ha desarrollado una serie de soluciones de seguridad basadas en Zero Trust, incluyendo la plataforma IBM Security Verify, que ofrece autenticación multifactor y gestión de identidades. IBM también ha implementado Zero Trust en sus operaciones internas para proteger los datos y la infraestructura.

Netflix usa el enfoque de seguridad zero trust

Netflix: Netflix ha adoptado un enfoque de Zero Trust para proteger su infraestructura en la nube y asegurar los datos de los usuarios. La empresa utiliza autenticación continua y segmentación de red para minimizar el riesgo de ataques cibernéticos.

¿Cuál es el posicionamiento del Zero Trust Network en México?

ciberataques a empresas mexicanas

En México, el concepto de Zero Trust Network está ganando tracción a medida que las empresas y organizaciones buscan mejorar sus posturas de ciberseguridad. La adopción de Zero Trust en México se ve impulsada por varios factores:

Incremento de ciberataques: México ha experimentado un aumento en los ciberataques, lo que ha llevado a las empresas a buscar enfoques de seguridad más robustos. Zero Trust ofrece una solución eficaz para proteger contra amenazas internas y externas.

Regulaciones de protección de datos: Las regulaciones de protección de datos, como la Ley Federal de Protección de Datos Personales en Posesión de los Particulares (LFPDPPP), requieren que las empresas implementen medidas de seguridad adecuadas para proteger la información personal. Zero Trust ayuda a cumplir con estas regulaciones al asegurar que solo los usuarios autorizados puedan acceder a los datos sensibles.

Adopción de tecnología en el sector financiero: El sector financiero en México ha sido un líder en la adopción de tecnologías de seguridad avanzadas. Los bancos y otras instituciones financieras están implementando Zero Trust para proteger los datos de los clientes y cumplir con las normativas de seguridad.

Iniciativas gubernamentales: El gobierno mexicano está promoviendo la adopción de tecnologías de ciberseguridad para proteger la infraestructura crítica y los datos del gobierno. Esto incluye la promoción de principios de Zero Trust en las agencias gubernamentales.

¿Cómo adoptar el Zero Trust Network permite proteger APIs y crear arquitecturas seguras?

API Security with Zero trust

Las APIs (interfaces de programación de aplicaciones) son componentes esenciales en las arquitecturas modernas, permitiendo la integración y comunicación entre diferentes sistemas y servicios. Sin embargo, las APIs también representan un vector de ataque significativo si no se protegen adecuadamente. La adopción de Zero Trust Network proporciona una capa adicional de seguridad para las APIs y ayuda a crear arquitecturas más seguras mediante:

Autenticación y autorización estrictas: Implementar controles de acceso granulares para cada API, asegurando que solo los usuarios y aplicaciones autorizados puedan interactuar con ellas. Esto incluye el uso de tokens de acceso y la autenticación multifactor para validar cada solicitud.

Segmentación de red y microsegmentación: Dividir la red en segmentos más pequeños y aplicar políticas de seguridad específicas a cada segmento. Esto limita el acceso a las APIs y reduce la superficie de ataque en caso de una brecha de seguridad.

Monitoreo y análisis continuo: Utilizar herramientas de monitoreo para detectar y responder a actividades sospechosas en tiempo real. Esto incluye el análisis de tráfico de API para identificar patrones anómalos y potenciales intentos de ataque.

Cifrado de datos en tránsito y en reposo: Asegurar que todos los datos transmitidos a través de las APIs estén cifrados para protegerlos contra interceptaciones y manipulaciones. Además, cifrar los datos en reposo para garantizar que la información sensible permanezca protegida incluso si se accede a ella sin autorización.

Políticas de acceso basadas en el contexto: Implementar políticas de acceso que consideren el contexto de la solicitud, como la ubicación del usuario, el dispositivo utilizado y el comportamiento habitual. Esto permite una autenticación y autorización más precisa y reduce el riesgo de acceso no autorizado.

Desarrollo seguro y pruebas rigurosas: Adoptar prácticas de desarrollo seguro y realizar pruebas de seguridad exhaustivas en las APIs para identificar y mitigar vulnerabilidades antes de que se desplieguen en producción.

En resumen, el Zero Trust Network es un enfoque de seguridad esencial en el panorama actual de amenazas.

20

En SPS, implementamos un sistema de seguridad en las APIs, lo que permite protegerlas de ser vulneradas, volviéndolas prácticamente invisibles.

Si te interesa conocer más detalles sobre este tipo de implementaciones en tu organización, te invitamos a escribirnos directamente al correo: contactoSPS@spsolutions.com.mx

Con gusto podemos explorar sus alcances dentro de un caso de uso en tu compañía.

 

Categorías
Dark Services MuleSoft OCI Zero Trust

A Ray of Light…How to consume a MuleSoft Dark Service API with the Netfoundry.io NodeJS SDK?

A Ray of Light…How to consume a MuleSoft Dark Service API with the Netfoundry.io NodeJS SDK?

A ray of light in the middle of darkness can save your life.

In 1998 Madonna released one of her finest albums whose name was Ray of Light. That song marked the lives of many people during that year. The song was played all over the world.

In this article, we will see how the NodeJS Netfoundry.io SDK can spark the light to consume a Dark Service API. A ray of light within your code is the spark to consume your Dark Services in a highly secured manner.

In our previous article, we’ve learned how to expose a Dark Service API using Netfoundry.io, MuleSoft Anypoint Platform, and Oracle Cloud Infrastructure. In that article, we’ve explained the procedure to deploy APIs as Dark Services and access them from a terminal (laptop) that is sitting on a completely different network. That is already very valuable and powerful at the same time, but we can go even further. And if you are wondering what do we mean by going even further? Just keep reading the article.

 

(Property of Netfoundry.io)

What do we mean by the app is the new edge?

The API consumer (the app) is going to contain the necessary elements to connect with the Dark Service API. The invisibility of the dark service will be lighted (if you will) through the application. The application, through the strong identity, will be entitled to consume the API, not the server, nor any other application running in the same environment, just the entitled application. In fact, for the rest, the Dark Service will remain…pretty much invisible.

This goes beyond just protecting the API with any type of authentication mechanism. When we have a Dark Service API, not only that consumers need to be authenticated to use it, but the strong identity is going to allow us to make it visible, to the rest of the world the Dark Service will remain invisible…

When we incorporate classic mechanisms to authenticate/authorize consumers for our public APIs, for example, OAuth 2.0, even though we add controls to avoid non-authorized consumers to use our APIs, the truth is that our API remains visible to pretty much everyone. A non-authorized consumer may be able to try to get access, to fuzz the requests, to guess the credentials, and in the worst case scenario: to consume it.

With Netfoundry.io we can make our APIs visible just for valid consumers, and invisible to the rest of the world. The consumer application is the edge and is what will contain the right elements to reach the APIs. And that is exactly what we are going to share in this article.

Netfoundry.io offers different SDKs for both enabling Dark Services and consuming them. There are different programming languages you can use for those SDKs, for example, Java, NodeJS, Python, C, Go, etc.

In my case, I will use the NodeJS SDK to consume the Dark API that I published in this article. We have the API already deployed (following the mentioned article) in the MuleSoft Anypoint Platform:

My Dark Service API

This consumer endpoint: http://darskide.api.com is reachable through the internet, but invisible at the same time. Try to access it and you will not reach it. The question is: how can an application get access to it? The response is: through Netroundry.io as we explained in the previous article. But now we will share how the identity can be incorporated into your code that consumes the API, in this case, a very simple NodeJS application.

Our scenario is the following:

a) We need to consume the API from the NodeJS application running in a Digital Ocean droplet

b) As we explained in our previous article, our API is deployed in MuleSoft inside a private Oracle Cloud subnet

c) The API is not reachable from the internet. But we have turned it Dark (invisible) using Netfoundry

d) The NodeJS application running in Digital Ocean will be able to consume the API, and it will be the only piece of software within that droplet that can reach the API (darkside.api.com).

The previous diagram depicts the idea of what we want to achieve. And as you can see the only piece of light that can reach our dark service is that small NodeJS consumer application.

The steps you need to take are:

• Follow this article.

• Create a new endpoint at the Netfoundry.io console

• Download the identity of the endpoint

• Download the NodeJS dependency to incorporate the Netfoundry SDK
• Create a very simple NodeJS application

• Use the identity generated in step #3

• Test your application

 

Let’s create the new endpoint. Go to your Netfoundry.io console and head to the endpoint section:

Click on the blue plus button, and then give it a name and download the key (jwt file):

Then, add this endpoint to the AppWAN:

 

Now, using the ziti-edge-tunnel command line utility:

 

# enroll from a token file
./ziti-edge-tunnel enroll –jwt ./myDarkConsumer.jwt –identity ./myDarkConsumer.json

 

That will produce a json file by the name myDarkConsumer.json that will represent our identity.

Now is the time to create our consumer API code. But first, we need to download the NodeJS dependency. The complete documentation can be found here: https://github.com/openziti/ziti-sdk-nodejs

npm i @openziti/ziti-sdk-nodejs

Once you install the ziti SDK, create a file with the following code and name it callMyDarkService.js:

import ziti from ‘@openziti/ziti-sdk-nodejs’;

const zitiIdentityFile = process.env.ZITI_IDENTITY_FILE;
// Authenticate ourselves onto the Ziti network
await ziti.init( zitiIdentityFile ).catch(( err ) => { /* probably exit */ });

const on_resp_data = ( obj ) => {
console.log(`response is: ${obj.body.toString(‘utf8’)}`);
};

// Perform an HTTP GET request to a dark OpenZiti web service
ziti.httpRequest(
undefined,
http://darkside.api.com/’, // Dark Service HTTP URL
‘GET’,
‘/api/people/1’, // path part of the URL including query params
[‘Accept: application/json’ ], // headers
undefined, // optional on_req cb
undefined, // optional on_req_data cb
on_resp_data // optional on_resp_data cb
);

Set the environment variable to point to the identity file:

export ZITI_IDENTITY_FILE=/path_to_your_identity/myDarkConsumer.json

And execute your code:

node callMyDarkService.js

The result:

root@rcarrascogb2:~/nf/samples/node# node callMyDarkService.js
on_req entered: { req: 94757361460352 }
on_resp entered: {
req: 94757361548992,
code: 200,
status: ‘OK’,
headers: {
‘Transfer-Encoding’: ‘chunked’,
‘strict-transport-security’: ‘max-age=15768000’,
allow: ‘GET, HEAD, OPTIONS’,
etag: ‘»ee398610435c328f4d0a4e1b0d2f7bbc»‘,
‘x-frame-options’: ‘SAMEORIGIN’,
vary: ‘Accept, Cookie’,
‘Content-Type’: ‘application/json’,
date: ‘Wed, 21 Dec 2022 22:59:08 GMT’
}
}
response is: {«name»:»Luke Skywalker»,»height»:»172″,»mass»:»77″,»hair_color»:»blond»,»skin_color»:»fair»,»eye_color»:»blue»,»birth_year»:»19BBY»,»gender»:»male»,»homeworld»:»https://swapi.dev/api/planets/1/»,»films»:[«https://swapi.dev/api/films/1/»,»https://swapi.dev/api/films/2/»,»https://swapi.dev/api/films/3/»,»https://swapi.dev/api/films/6/»],»species»:[],»vehicles»:[«https://swapi.dev/api/vehicles/14/»,»https://swapi.dev/api/vehicles/30/»],»starships»:[«https://swapi.dev/api/starships/12/»,»https://swapi.dev/api/starships/22/»],»created»:»2014-12-09T13:50:51.644000Z»,»edited»:»2014-12-20T21:17:56.891000Z»,»url»:»https://swapi.dev/api/people/1/»}

We can call our API which is sitting privately within a private Oracle Cloud Infrastructure subnet, from a Digital Ocean server, and through the internet.

But if we do a ping to the darkside.api.com hostname from the Digital Ocean server, see what happens:

root@rcarrascogb2:~/nf/samples/node# ping darkside.api.com
ping: darkside.api.com: Temporary failure in name resolution

If we try telnet:

root@rcarrascogb2:~# telnet darkside.api.com 80
telnet: could not resolve darkside.api.com/80: Temporary failure in name resolution

From my Digital Ocean server, we can call the Dark API through the NodeJS application, but outside the application, we cannot reach the API. We cannot resolve the hostname, and most importantly we cannot even reach it. Isn’t that interesting?

 

The ray of light that we can use to light the darkness is Netfoundry’s SDK. And as you could see is very simple to incorporate into your code. With that, your consumers’ effort to consume your Dark APIs is very low.

 

In the next article, we’ll elaborate on the idea of how to automate the enrollment of your API consumers.

Categorías
Dark Services Zero Trust

The Dark Side of The Cloud: How to create APIs as Dark Services using MuleSoft with Netfoundry.io on top of Oracle Cloud Infrastructure

How to create APIs as Dark Services using MuleSoft with Netfoundry.io on top of Oracle Cloud Infrastructure. The Dark Side of The Cloud

Wait…what?

The dark side of the force, the dark side of the moon. I’m not too much into that, I’m not a Star Wars or Pink Floyd fan at all. But I need to accept and recognize that the fact that they used the term dark in one of their most iconic and/or relevant moments, was such a great idea and success at the same time. We all remember Darth Vader telling Luke to come to the dark side of the force (or something like that). And when someone wants to sound interested in music, it is quite common to hear things like: “The best album composed by Floyd was The Dark side of the Moon. They were such a genius”. And well, Star Wars and Pink Floyd indeed influenced pop culture in such a way that they remain valid to these days. I am a big fan of Japanese streetwear and one of my favorite designers is 順 高橋 (Jun Takahashi) who released 2017 a set of t-shirts, and crewnecks inspired by the already mentioned best album of Pink Floyd.

Well, that was not a very orthodox way to start a technology article related to MuleSoft, Netfoundry, and Oracle Cloud. But I can say that the term Dark Service is just as appealing as the Dark side of the moon, or the Dark side of the force. And that’s what I am going to try to do in this article.

 

The first thing to keep in mind and to recognize is the following:

Gartner was so right on this. We are living it. Our APIs are constantly being attacked, we must do a better job in this regard. But at the same time, since one of the most common use cases for APIs is to expose them to the external world with the idea that developers from other organizations can use them to build their applications, then it is unavoidable to make them public and to allow them to be accessed from the internet, with all the consequences that this implies.

There are different options to apply security policies to our APIs. For example:

• To authenticate the consumer with a username and password

• To make the consumer first obtain an access token, with an OAUTH 2.0 dance

• Mutual Authentication

• In the SOAP world, incorporating WS-Security

• Digital signatures

• Etcétera

And all those mechanisms are valid, but we still need to avoid attackers trying to cause a DoS (Denial-of-service), as well as try to fuzz the requests; and/or try to avoid them skipping rate-limiting mechanisms we have in place. We, also, must be sure about the validity of the identities consuming our APIs.

 

We need to make them invisible to the attackers to avoid most of the things I am referring to. Invisible? Yes, you’ve read it well.

 

But how can I make them invisible but at the same time reachable from the internet and consumable by developers? That can be quite a challenge, and a non-sense at the same time.

 

To continue with the ideas that I’ve shared at the beginning of this article, I can also mention that one of my favorite music bands is OMD (Orchestral Manoeuvres in the Dark). They had several hits in their career, such as Secret, Tesla Girls, Electricity, etc. And just as OMD used to make those Orchestral Manoeuvres in the Dark, we need to make something similar for our APIs if we want to turn them into the dark side of the cloud.

 

Dark services can be accessed through a public environment (internet) but just for the consumers we want, and for the rest, they will remain invisible. But we are not going to use VPNs or whitelisting in our Firewall. We are not going to open new ports into our firewall, nor use a Reverse-Proxy, none of that. All our resources are going to remain private.

 

This means that our APIs are not going to be exposed to the internet, they are going to be sitting privately. But with Netfoundry.io we will let external organizations use them but in a very highly secured way. Our public APIs will be turned into dark services: reachable for valid consumers, unreachable for the rest.

High-level diagram showing the different pieces involved in our Dark Services intentions

The previous diagram is very high level but is good enough to explain our objective. Let’s explain it a little bit deeper:

  1. We have Oracle Cloud (OCI), in my case using the us-ashburn-1 region; within OCI we have a VCN divided into two subnets, but privates.

    2. In one of the subnets, we have a Netfoundry Edge Router

    3. In the second subnet, we have MuleSoft Runtime where our APIs are being developed

    4. We have external developers and organizations who want to consume our APIs through the internet.

    As you can see our MuleSoft Runtimes are not visible from the internet, but at the same time they are reachable to our consumers, using the Netfoundry.io technology.

What do we need to make this possible?

  1. OCI free trial (30 days). We will use two computing instances: one for the Netfoundry Edge Router and one for the MuleSoft Runtime

  2. MuleSoft Anypoint Platform free trial. We will register our Runtime into the Control Plane.

  3. Netfoundry.io teams account. We will provide an overlay network to turn our APIs to the dark side of the cloud.

  4. Your laptop. Where you will be able to consume the APIs

Let’s do it!
I have created a new VCN, which is divided into the following subnets:

We have two private subnets and one public subnet. The public subnet is not going to be used at all. The two private ones:

 

  1.  Private Subnet-mydark-vcn. Here we will provide our Netfoundry Edge Router

  2.  Private Subnet-mydark-mule-vcn. Here I will deploy a MuleSoft Runtime

    Before we proceed to provision the rest of the infrastructure, we will create the elements in Netfoundry.

We are going to create an Edge Router with this information:

Once you click on the Create button, you will see this:

 

Download the key, since you will use it during the provision of the Edge Router at OCI. We will provision it through the Market Place. Let’s go for it.

Let’s head to the OCI Marketplace:

 

A search for Netfoundry:

 

Click on the NetFoundry Edge Router and you will land here:

Select your compartment, in my case: darkservices. And click on the checkbox after you read the terms and conditions. And finally, click on Launch Instance.

Then, we selected the following shape:

And the following networking:

And at the Advanced Options section, configure this:

Which is this script:

#!/bin/bash
/opt/netfoundry/router-registration {key}

Where key is the value that you got after creating the Edge Router in the previous steps.

Then just click on the Create button:

After that, the compute instance will start its provisioning process and after a couple of minutes you should see it running:

And at the Netfoundry.io console, the Edge Router should be in green:

Now is the time to provision the Compute Instance to install the MuleSoft Runtime.

 

In the same compartment we will provision a compute instance with the following characteristics:

 

And:

And finally:

Be careful selecting the private subnet we’ve created for our MuleSoft Runtime. After a couple of minutes your instance should be up and running:

Since this compute instance is private (IP address 10.0.2.202), and we do not want to use a bastion that we can use to jump into it, we will use OCI cloud shell to connect to it.

 

Use the cloud shell functionality to connect to private networks and use ssh to connect to the compute instance:

Once you’ve connected to the private subnet, use ssh:

nce at the compute instance, install JDK 11 and the MuleSoft Runtime.

To install the MuleSoft Runtime, download it from here:

 

https://www.mulesoft.com/lp/dl/anypoint-mule-studio?source=post_page—–20de63cde426——————————–

 

Upload the zip file into the compute instance. To do that, use the cloud shell functionality to upload it:

The file will be uploaded to the cloud shell terminal, then use the scp command to move it to the compute instance:

I have structured my directories like this:

/u01/mule ← I will unzip the mulesoft runtime there

/u01/java ← I will unzip the JDK 11 file in there

Now is time to register the MuleSoft Runtime into the Anypoint Platform control plane:

Go to Runtime Manager and create a new server:

Type a name for your server and copy the command:

Paste the command under your $MULE_HOME/bin directory, once it finishes you will see this:

At your anypoint platform console, you should see this:

Now is time to start our MuleSoft Runtime:

nohup ./mule > mule.out &

And check that log file the following is written

*********************************************************************
* Started DefaultSchedulerService *
* *
* Resolved configuration values: *
* *
* Pooling strategy: UBER *
* gracefulShutdownTimeout: 15000 ms *
* uber.threadPool.maxSize: 158 *
* uber.threadPool.threadKeepAlive: 30000 ms *
* *
* These can be modified by editing ‘conf/scheduler-pools.conf’ *
**********************************************************************
INFO 2022-12-12 21:19:24,779 [WrapperListener_start_runner] [processor: ; event: ] com.mulesoft.agent.services.healthcheck.AgentHealthCheckService: Initializing HealthCheck service
INFO 2022-12-12 21:19:24,801 [WrapperListener_start_runner] [processor: ; event: ] com.mulesoft.agent.services.artifactvalidator.AgentApplicationValidatorService: Initializing Artifact Validator service
INFO 2022-12-12 21:19:24,802 [WrapperListener_start_runner] [processor: ; event: ] com.mulesoft.agent.services.artifactvalidator.AgentApplicationValidatorService: Total validators loaded: 0

**********************************************************************
* Started domain ‘default’ *
**********************************************************************

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+ Mule is up and kicking (every 5000ms) +
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

**********************************************************************
* – – + DOMAIN + – – * – – + STATUS + – – *
**********************************************************************
* default * DEPLOYED *
*********************************************************************

Let’s deploy a very simple API into our newly created Runtime. Let’s go to the API Manager section in our anypoint platform console and create a new API:

Configure it as follows:

And:

Click on the Next button, and configure it as follows:

Then we will configure the API to point to this implementation:

(We are continuing with the idea of the Dark side of the force that we’ve mentioned in the introduction, and because of that we are using the Star Wars API).

On purpose, we are exposing the API at port 8081 and using HTTP only. Then click on the Next button and finally on the Save & Deploy button.

Now is the time to test it. We will do it directly from the compute instance since the only way to hit the Runtime is from within that subnet:

As you can see we got a valid result.

 

Alright, we are finally at the point where we wanted to be:

 

We have an API that is just accessible within a private subnet, but we want to make it accessible from/within the internet, but just to specific consumers. That is what the Netfoundry.io magic brings to the table.

In previous steps, we’ve created an Edge Router which is already registered into my Netfoundry.io console:

Now we need to create a new Service in Netfoundry that we can use to reach our API:

We are telling to Netfoundry that we would like to resolve the name: darkside.api.com through port 80 and route it to our private MuleSoft Runtime IP address which is 10.0.2.202.

 

Now we just need to create and/or assign it to an AppWAN. I will reuse one that I already had, which is accessible from my laptop:

Our network should look like the following image:

As you can see the red box is inside a completely different network to where I am (mylaptop). Is sitting very privately within an OCI subnet. No one from the internet can reach it.

 

My edge client now should reflect the configuration:

Is time to test it, let’s do it from my browser:

And the magic is there. I am accessing the private API from my laptop, without having to make public a single resource from OCI. Everything that we provisioned is private: the edge router and the MuleSoft runtime. No inbound ports have been opened to the internet. No reverse-proxies, no nothing.

We have a dark service serving at http://darkside.api.com, being accessed from the internet, but I am the only valid consumer so far. The darkside.api.com name does not even exist on the internet, but I can resolve it thanx to Netfoundry.io.

In summary, we have these couple of compute instances in OCI:

Both of them are private. The first one is where our Netfoundry Edge Router is being deployed, and the second one is our MuleSoft Runtime.

Using the Netfoundry.io overlay network we can expose a Dark Service on the internet to access our MuleSoft APIs, but just specific consumers can reach them. Only the consumers that we want, and/or trusted consumers will reach our APIs. For our API initiatives, this is a great mechanism to expose in a very secure fashion our assets. Think about it. With this, we can avoid attackers on the internet can reach our APIs. We can avoid exposing the endpoint to the internet and therefore make it visible to attackers, they won’t be able to scan open ports, to start fuzzing requests, etc.

Categorías
Responsabilidad Social Uncategorized

SPS reúne donativos para la Fundación Mosaico Down

SPS reúne donativos para la Fundación Mosaico Down

Impulsados por la voluntad de ayudar, el equipo de SPS, realizó una campaña interna entre los colaboradores de la empresa, con la finalidad de reunir donativos para la Fundación Mosaico Down.

La fundación Mosaico Down, tiene la misión de mejorarla calidad de vida de las personas con Síndrome de Down y Discapacidad Intelectual leve.

La Fundación Mosaico Down brinda educación especial por medio de un método académico que mezcla lo mejor del modelo educativo global y el método Montessori.

Además, su visión consiste en favorecer al desarrollo productivo e inclusivo de estas personas en todos los ámbitos de su vida. Si te interesa participar o contactar a Mosaico Down, te invitamos a visitar su sitio web.

Categorías
Responsabilidad Social Uncategorized

SPS visita y apoya al refugio Xollines​

SPS visita y apoya al refugio Xollines

El día sábado 10 de diciembre del 2023, el equipo de SPS visitó el Refugio Xollines para entregar donativos que se recaudaron durante los meses previos a la visita.

La mayoría de los colaboradores de SPS se unió a esta iniciativa, enviando donaciones como: alimentos, medicamentos, camas, ropa, collares.


El Refugio Xollines, ubicado en Teotihuacán Estado de México, es un refugio de animales que están en situación de abandono y maltrato extremo, pero además es un centro de adopción responsable que perritos que ya fueron rehabilitados física y emocionalmente para que vuelvan a tener confianza en los seres humanos y encuentren un nuevo hogar.

Durante nuestra visita, los compañeros de SPS también se dieron tiempo de divertirse y jugar con los caninos. 

Categorías
Industria tecnológica

Acompáñanos al Salesforce World Tour 2024 en la Ciudad de México: descubre los últimos avances sobre Inteligencia Artificial Generativa con Salesforce

Acompáñanos al Salesforce World Tour 2024 en la Ciudad de México: descubre los últimos avances sobre Inteligencia Artificial Generativa con Salesforce

Con la llegada de la Inteligencia Artificial (IA) y sus rápidos avances, sería un error no considerar la integración de estrategias soportadas con inteligencia artificial para impulsar el crecimiento empresarial. 

Para ser precisos, el uso de la inteligencia artificial implementada en procesos de negocio, permite tener procesos mejor optimizados; ágiles, sostenibles y, por ende, la reducción de costos operativos.

Salesforce World Tour en Ciudad de México 2024

El Salesforce World Tour en Ciudad de México 2024, es un espacio creado para difundir la innovación de la tecnología del ecosistema Salesforce mediante sesiones de conocimiento y exposición de empresas especializadas, para una mayor comprensión y adopción de estas nuevas tecnologías.

Definitivamente este espacio es una oportunidad para que líderes empresariales y de negocio, profesionistas, estudiantes y entusiastas de la tecnología, puedan aprender sobre las actualizaciones y explorar cientos de posibilidades que pueden ser aplicadas a todas las industrias, así como conocer soluciones, servicios y productos enfocados en su sector, mediante la proyección de “demos” que han sido ya aplicadas en la práctica.

SPS un Partner estratégico con una amplia experiencia en integración con MuleSoft

SPS es una empresa mexicana de consultoría con una trayectoria de 16 años implementando soluciones tecnológicas. Nos enfocamos en orientar y acompañar a las organizaciones (nuestros clientes), en su camino en la integración y automatización de procesos y modernización de sus sistemas.

Nuestra historia con MuleSoft comenzó en el año 2014, cuando descubrimos todos los beneficios que ofrece para una aplicación eficiente de estrategias, así que comenzamos a utilizarla en nuestros proyectos. Con el tiempo nos hemos mantenido actualizados, y contamos con un equipo de consultores especializados y certificados en tecnología MuleSoft.

La oferta que tenemos con MuleSoft es muy variada, y siempre puede ajustarse y personalizarse a las necesidades operativas y herramientas tecnológicas de nuestros clientes, pero podemos resumirla en los siguientes puntos:

  • Habilitamos experiencias digitales para los usuarios de nuestros clientes

  • Integramos los sistemas de las organizaciones entre sus propios sistemas o con los de terceros

  • Habilitamos canales digitales como por ejemplo: Chatbots, IA generativa, Extracción de información de documentos digitalizados

  • Implementamos MuleSoft como medio de comunicación para Data Cloud
  • Impartimos talleres de principios de diseño de APIs para nuestros clientes 
  • Creamos bots inteligentes a través de MuleSoft y los integramos con Slack

  • Realizamos assesments tanto de implementación como de análisis de seguridad y vulnerabilidades sobre las APIs expuestas

  • Administramos servicios de la nube de MuleSoft

  • Ofrecemos cursos de MuleSoft tanto de desarrollo como de arquitectura, preparando a los clientes para certificarse

  • Aseguramos las APIs, incorporando elementos que eviten que tus APIs puedan ser vulneradas

SPS como Patrocinador Gold: ¿cuáles serán nuestros momentos más destacados?

Este próximo 22 de mayo del 2024, estaremos participando con un Patrocinio Gold durante el evento. Queremos que esta participación no este únicamente enfocada en nuestro posicionamiento, también buscamos generar valor y una forma de hacerlo es poder compartir parte de nuestro conocimiento con los asistentes. Por este motivo tenemos planeada la presentación de tres sesiones de conocimiento y la dinámica de una rifa.

A continuación les presentamos todos los detalles:

  1. Participaremos con la sesión: “Construyendo sistemas para el futuro: la convergencia entre APIs e Inteligencia Artificial y los LLMs como motores de la innovación”

    Durante esta plática exploraremos como se mezclan estas tecnologías, cómo podemos potencializar sus funciones y formas de integrarlas. Esta conferencia la ofrecerá nuestro CTO: Rolando Carrasco y nuestro Líder de Arquitectura: Arturo González. ¡Te esperamos a las 4:30 pm en el Teatro Einstein! 

  2. A las 11:00 am en nuestro Stand, proyectaremos una DEMO, la titulamos: “Cómo implementar un Asistente Digital con MuleSoft”, durante esta proyección compartiremos información relevante sobre como realizamos este tipo de integraciones.

  3. A la 1:00 pm nuestro consultor Luis Manjarrez, realizará una segunda proyección de una DEMO: “Automatiza tus procesos de negocio haciendo uso de la IA y el ecosistema de MuleSoft y Salesforce. Aquí exploraremos como podemos aprovechar la IA en procesos repetitivos dentro de la organización. ¡No te pierdas ninguna de estas DEMO, pues tendremos sorpresas!

  4. Finalmente, en punto de las 5 pm, realizaremos nuestra RIFA de 3 increíbles LEGOS, con la finalidad de cerrar con broche de oro nuestra participación en el evento. Si quieres participar en esta RIFA, deberás seguirnos en nuestra página de LinkedIn, haber visitado previamente a nuestro stand en un horario de 9 am a 5 pm, responder la pregunta de nuestro staff y llenar correctamente todos tus datos en la papeleta y depositarla en la urna. ¡No te pierdas la oportunidad de ganar!

Como ya lo repasamos, estamos seguros de que este evento será valioso para ti, por lo que te invitamos a asistir  junto a tu equipo de trabajo y así ampliar su conocimiento sobre tecnología, Inteligencia Artificial, implementaciones. En este evento también podrás conectar con clientes, socios, empresas, proveedores y hasta encontrar oportunidades laborales. 

Te extendemos una cordial invitación a que nos acompañes, visites nuestro stand, asistas a nuestras sesiones, y te registres al Salesforce World Tour en Ciudad de México 2024 mediante el siguiente enlace:

Categorías
Zero Trust

Introducing Dark API Portals. How to cross the gate and access them. Part 1 of 3

Introducing Dark API Portals. How to cross the gate and access them. Part 1 of 3

We’ll learn how to create & deploy them in Oracle Cloud Infrastructure (OCI), using MuleSoft Anypoint Platform and NetFoundry./OpenZiti.

World of Warcraft has been a very successful gaming franchise for many years. Full disclosure: I’ve never played it — it’s just not my type of game. Despite my indifference, World of Warcraft has been successful enough to captivate many other people around the world.

In 2008 (almost 15 years ago), the book “Beyond the Dark Portal” was published. It is a story that takes place in the World of Warcraft fantasy setting, and as its title suggests, has to do with a Dark Portal, which coincidentally relates to the topic we will cover in this article. Although we will talk about APIs, we will be covering how to prevent malicious forces from attacking them, which is kind of similar to what the book is about!

In two previous articles, here and here, we covered the concepts of Dark Services; specifically, how you can publish them and ultimately consume them using MuleSoft Anypoint Platform and OpenZiti/NetFoundry.io technologies.

The fundamental idea of Dark Services is to be invisible to attackers and just be visible to your real consumers and applications.

In those articles, we learned the relevance of publishing APIs as Dark Services in an era when hacks and malicious attacks are happening every single second. We covered how to make your APIs invisible to attackers without opening a single port of your firewall while still allowing public consumption of your APIs.

We still must consider how we can allow potential consumers to search for our Dark API Services.

If the whole idea is to make our services invisible, should we be publishing them through a public API Portal? We would be exposing something which we want to keep as safe as possible. Yet if we do not expose our services publicly, we lose the opportunity for external developers to interact with us.

It sounds like a challenging task, right? On the one hand, we want our APIs to be easily consumed and discoverable; on the other, we want them to be secure and invisible to attackers. We need a way to balance these two opposing initiatives.

The solution is what we’ve called Dark API Portals.

And so, you may be asking: Just what are Dark API Portals?

Let’s go over some of the characteristics of a Dark API Portal:

  1. A Dark API Portal provides a public user experience, without the need for agents, courtesy of OpenZiti BrowZer; it uses web page authentication to permit access to the private application (the Dark Portal) which has no address on the public internet. Only valid identities can gain access to the Portal. Your Dark API Portal is pretty much invisible to the world but reachable to your registered users.

  2. A Dark API Portal hosts Dark API Services, which means that an external developer (or an internal one, depending on the use case) will be able to subscribe to Dark API Services just as they could for services hosted in any other public API Portal.

  3. The developer who wants to access the Dark API Portal will follow the same process as that of any normal API Portal: subscribe to the desired APIs; obtain a client_id/client_secret (or in the case of a provider who requires mTLS, register a certificate); etc. Apart from following the typical API enrollment process, the developer will also need to provide a strong identity to connect to the OpenZiti/NetFoundry overlay network. In other words, to gain access to the API, a developer will not only need to exchange credentials but will also need to have a strong identity issued by NetFoundry.io to use any of its SDKs, such as JAVA, Python, Go, NodeJS, etc.

  4. From the Dark API Portal, the developers will gain access to the SDKs needed to consume the Dark Services.


You may be wondering now why the lengthy explanation was necessary if we can easily use any type of API portal and control user access to it via username/passwords and Multi-Factor Authentication (MFA). Well, if your interest is to minimize the risk in terms of your public assets, as much as possible, then having it open to the world flies in the face of that. Furthermore, if your APIs need to be as secure as possible, then to have them visible and available to the world is also in conflict with the desired level of security.

None of the current API Management offerings in the market offers a way to publish Dark API Portals and/or Dark Services.

Conventional API portals allow developers to subscribe to APIs; as a result, the API provider creates for them a set of credentials to enable the consumption of the APIs. Conventional API Portals also allow anyone with access to view examples of the APIs, documentation, and Sandboxes which attackers may then use to analyze the usage patterns and consequently try to compromise them.

With Dark API Portals, we can avoid all public information around your APIs being exposed, while at the same time ensuring that they are visible only to your desired consumers. Only your authorized developers will be able to subscribe to the APIs and view all of their details.

Crossing the gate of a Dark API Portal will allow you to see things that no one else can see.

The wardrobe that takes you to Narnia. The Chronicles of Narnia.

Entering a Dark API Portal will allow developers to browse, subscribe, and consume APIs that no one else can.

In the Chronicles of Narnia, crossing through a portal into Narnia is done by way of regular, well-known methods: in our case, we cross through a portal via a web browser. The user/consumer/developer will use a common browser (e.g. Google Chrome) to gain access to the Dark API Portal by executing the steps of the following flow:

As you can see in the above flow, OpenZiti BrowZer integrates with an Identity Provider (IdP), which will coordinate the authentication process for users who want access to the Dark API Portal. Once the user has successfully authenticated, control is returned to OpenZiti BrowZer which then uses the user identity provided by the IdP to obtain authorization for access to the NetFoundry.io overlay network. Depending on the authorization granted, the user identity may or may not be able to access the application (using the App WAN concept); if authorization has been granted, then the content is served.


The following is so important, it bears repeating:

 

The Dark API Portal is invisible to everyone except valid users. On the public internet, API Portals are visible to even invalid users who may try to attack and compromise them.

So how do we build/create a Dark API Portal?


Property of Netflix. DARK

 

In this series of articles we are going to use the following:

  1. MuleSoft as the API Manager to expose and manage the APIs
  2. MuleSoft Admin APIs to expose all the functionality necessary to create a custom API Portal to allow the listing of APIs with their contracts and also to allow external subscription to the APIs
  3. NetFoundry.io and its APIs to interact with the Dark API Portal to create a new endpoint and attach it to an App WAN
  4. Netfoundry.io/OpenZiti BrowZer to allow users to gain access to the Dark API Portal
  5. A React.js web application, which is the Dark API Portal, running on a fully private compute instance deployed in a private subnet within Oracle Cloud Infrastructure
  6. A Mule Runtime server which also runs on a fully private compute instance deployed in a private subnet within Oracle Cloud Infrastructure
    A NetFoundry.io Edge Router deployed on a private subnet within Oracle Cloud Infrastructure
  7. Postman Flows to explain the steps

(Notice that we are not going to open a single port in the Firewall to make both the Dark API Portal and its Dark Services available from an external network).

The following diagram describes how the different elements are distributed:

Oracle Cloud Infrastructure

 

 

As you can see, all is private within the VCN; the consumers are not connected directly to the services, nor do they even know where they are.

Our Dark API Portal is sitting on that compute instance labeled as My Dark Portal within a Private Subnet. Also, within that very same Private Subnet, we have a Mule Runtime server which is completely private and reachable only through that subnet.

We also have our NetFoundry.io Edge Router sitting on a private subnet. There is nothing publicly available, nor do we have reverse proxies, bastions, or VPNs to allow access from outside of that VCN. The Security Lists have open ports just within the private subnets — nothing from the internet or other networks.

Alright, now we will explain how to use MuleSoft and NetFoundry.io to create the Dark API Portal.

 

Max & Ziggy getting together

Since the out-of-the-box API Portals are not prepared to become Dark, we will leverage the advanced

 

 functionality of their admin APIs to create them instead.

We need to create a web application that can interact with the API Manager (i.e. the MuleSoft Anypoint API Manager) to list the available APIs of a given organization and allow developers to subscribe to them. MuleSoft offers several resources to do so through its Access Management API. We just need a subset of the resources offered by the Access Management API. Specifically, we need the following:

  1. Authentication resource
  2. Organization resources to retrieve the organization ID
  3. The environment resource to retrieve the environment ID
  4. The API resource to get the list of APIs of a specific environment and a specific organization
  5. The API resource to get the details of a specific API
  6. The Application resource will be used to subscribe to the desired API to either create a new application or reuse an existing one
  7. A Tier resource, to get the different tiers of an API (e.g. silver, gold, platinum) which can be used to limit the number of calls a developer can make to an API
  8. A Contracts resource to subscribe to a created or existing application (as mentioned in point #6 of this list), to register with the desired API whose details were retrieved in step #5

Take a look at the following Postman Flow:

 

Postman Flow to create an Endpoint and associate it with an App WAN in NetFoundry

The Postman Flow and Collection are available here for your convenience.

At last! We have all the pieces in place now to create our Dark API Portal. In the next article, we will dive deep into how to use all those resources to make it happen. Stay tuned!

 

Summary:

We introduced the concept of Dark API Portals and how to implement them using MuleSoft Anypoint Platform and NetFoundry/OpenZiti
We described the relevance of creating them

We described the elements needed to make it happen
In the next two articles, you will learn in detail how to create them