• Skip to primary navigation
  • Skip to main content
  • Skip to footer
Logotipo de Bluetab

Bluetab

Targeted Innovation

  • Solutions
    • DATA STRATEGY
    • DATA FABRIC
    • AUGMENTED ANALYTICS
  • Software
    • TRUEDAT
    • FASTCAPTURE
    • TAILORED ENTERPRISE SW
  • About Us
  • Our Offices
  • Talent
  • Blog
  • Español

Blog

5 errores comunes en Redshift

December 15, 2020 by Bluetab Leave a Comment

5 errores comunes en Redshift

Alvaro Santos

Senior Cloud Solution Architect​

Share on twitter
Share on linkedin

Amazon Redshift se puede considerar como unos de los data warehouse más importantes de la actualidad y que ofrece AWS en su nube. Trabajando en Bluetab, hemos tenido el placer de usarlo en muchas ocasiones con nuestros momentos buenos / malos al igual que este año 2020. Por ello, hemos creado una lista con los errores más comunes que debéis evitar y que esperemos os sirvan de gran ayuda.

En Bluetab llevamos desde hace más de 10 años trabajando alrededor del dato. En muchos de los cuales, hemos ayudado en la evolución tecnológica de muchas empresas migrando sus entornos tradicionales analíticos y BI de Data Warehouse a entornos de Big Data.

Además desde la Práctica Cloud hemos participado en migraciones a la nube y nuevos desarrollos de proyectos de Big Data la nube de Amazon Web Services y Google Cloud. Toda esta experiencia nos ha permitido crear un grupo de personas muy cualificadas que piensan/trabajan por/para la nube.

Para ayudaros con vuestros trabajos en la nube, os queremos presentar los errores más comunes que hemos encontrado a la hora de trabajar con Redhisft, la herramienta de DW más importante que ofrece AWS.

Aquí tenéis la lista de ellos:

  1. Trabajar como si fuera un PostgreSQL.
  2. Cargar datos de aquella manera.
  3. Dimensionar mal el cluster.
  4. No hacer uso de workload management (WLM).
  5. Desentenderse del mantenimiento

Qué es Redshift

Amazon Redshift es un base de datos analítica (OLAP) en la nube muy rápida y totalmente administrada por AWS. Con ella se simplifica y mejora el análisis de datos utilizando SQL estándar compatible con la mayoría de las herramientas de BI existentes.

Las características más importantes de Amazon Redshift son:

  • Almacenamiento de datos en columnas: en lugar de almacenar datos como una serie de filas, Amazon Redshift organiza los datos por columna. Dado que solo se procesan las columnas involucradas en las consultas y los datos en columnas se almacenan secuencialmente en los medios de almacenamiento, los sistemas basados ​​en columnas requieren muchas menos I/O, lo que mejora enormemente el rendimiento de las consultas.
  • Compresión avanzada: las bases de datos columnares se pueden comprimir mucho más que las basados ​​en filas porque los datos similares se almacenan secuencialmente en el disco.
  • Procesamiento masivo paralelo (MPP): Amazon Redshift distribuye automáticamente la carga de datos y consultas en todos los nodos.
  • Redshift Spectrum: Redshift Spectrum le permite ejecutar consultas en exabytes de datos almacenados en Amazon S3.
  • Vistas materializadas: las consultas posteriores que hacen referencia a las vistas materializadas utilizan los resultados pre.calculados para ejecutarse mucho más rápido. Las vistas materializadas se pueden crear en base a una o más tablas de origen utilizando filtros, proyecciones, combinaciones internas, agregaciones, agrupaciones, funciones y otras construcciones SQL.
  • Escalabilidad: Redshift tiene la capacidad de escalar su procesamiento y almacenamiento aumentado el tamaño de cluster a cientos de nodos.

Amazon Redshift no es igual que otros sistemas SQL de base de datos. Para aprovechar adecuadamente todos sus beneficios es necesario que se sigan una buenas practicas, de esa manera el cluster funcionará de manera óptima.

1. Trabajar como si fuera un PostgreSQL

Un error muy común que cometemos al comenzar a usar Redshift, es suponer que Redshift es simplemente un PostgreSQL vitaminado y que partiendo de un schema compatible con él puedes empezar a trabajar con Redshift. Sin embargo, no podrías estar más equivocado.

Aunque es cierto que Redshift se basó en una versión antigua de PostgreSQL 8.0.2, su arquitectura ha cambiado radicalmente y ha sido optimizada durante años para mejorar el redimiendo para su estrictamente analítico. Por ellos es necesario:

  • Diseñar las tablas de manera adecuada.
  • Lanzar consultas optimizadas para entornos MPP.


Diseñar las tablas de manera adecuada

Cuando se diseña la base de datos ten en cuenta que algunas decisiones clave sobre el diseño de las tablas influyen considerablemente en el rendimiento general de la consulta. Unas buenas practicas son:

  • Seleccionar el tipo de distribución de datos óptima:

    • Para las tablas de hechos (facts) elige el tipo DISTKEY. De esta manera los datos se distribuirán en los diferentes nodos agrupados por los valores de la clave elegida. Esto te permitirá realizar consultas de tipo JOIN sobre esa columna de manera muy eficiente.
    • Para las tablas de dimensiones (dimensions) con un pocos de millones de entradas elige el tipo ALL. Aquellas tablas que son comúnmente usadas en joins de tipo diccionario es recomendable que se copien a todos los nodos. De esta manera la sentencia JOIN realizada con tablas de hechos mucho más grandes se ejecutará mucho más rápido.
    • Cuando no tengas claro como vas a realizar la consulta sobre una tabla muy grande o simplemente no tenga ninguna relación con el resto, elige el tipo EVEN. De esta forma los datos se distribuirán de manera aleatoria.
  • Usa la compresión automática permitiendo a Redshift que seleccione el tipo más optimo para cada columna. Esto lo consigue realizando un escaneo sobre un número limitado de elementos.


Usar consultas optimizadas para entornos MPP

Puesto que Redshift es un entorno MPP distribuido, es necesario maximizar el rendimiento de las consultas siguiendo unas recomendaciones básicas. Unas buenas practicas son:

  • Las tablas tiene que diseñarse pensando en las consultas que se van a realizar. Por lo tanto, si una consulta no encaja es necesario que revises el diseño de las tablas que participan.
  • Evite usar SELECT *. e incluye solo las columnas que necesites.
  • No uses cross-joins a no ser que sea necesario.
  • Siempre que puedas, usa la sentencia WHERE para restringir la cantidad de datos a leer.
  • Use claves de ordenación en las cláusulas GROUP BY y SORT BY para que el planificador de consultas pueda usar una agregación más eficiente.

2. Cargar datos de aquella manera

Cargar conjuntos de datos muy grandes puede tomar mucho tiempo y consumir gran cantidad de recursos del cluster. Además si esta carga se realiza de manera inadecuada también puede afectar el rendimiento de las consultas.

Por ello, es recomendable seguir estas pautas:

  • Usa siempre el comando COPY para cargar los datos en paralelo desde Amazon S3, Amazon EMR, Amazon DynamoDB o desde distintos orígenes de datos en hosts remotos.

 copy customer from 's3://mybucket/mydata' iam_role 'arn:aws:iam::12345678901:role/MyRedshiftRole'; 
  • Si es posible, lanza un solo comando en vez de varios. Puedes usar un fichero manifest o patrones para cargar varios ficheros de una sola vez.

  • Divide los archivos de datos de carga de tal modo que sean:

    • De igual tamaño, entre 1 MB y 1 GB, después de la compresión.
    • Un múltiplo del número de slices de tu cluster.
  • Para actualizar los datos e insertar datos nuevos de manera eficiente al cargarlos usa una tabla provisional.

  -- Crea una tabla provisional y, luego, complétala con los datos que se fusionarán.
  create temp table stage (like target); 

  insert into stage 
  select * from source 
  where source.filter = 'filter_expression';

  -- Usa una combinación interna con la tabla provisional para eliminar las filas de la tabla destino que se están actualizando.
  begin transaction;

  delete from target 
  using stage 
  where target.primarykey = stage.primarykey; 

  -- Inserta todas las filas de la tabla provisional.
  drop table stage;
  insert into target 
  select * from stage;

  end transaction;

  -- Elimina la tabla provisional.
  drop table stage; 

3. Dimensionar mal el cluster

A lo largo de los años hemos visto muchos clientes que tenían graves problemas de rendimiento con Redshift debido a fallos de diseño de sus BBDD. Muchos de ellos habían intentado resolverlos añadiendo más recursos al cluster en vez de intentar solucionar el problema de raíz.

Por ellos te propongo que sigas el siguiente flujo para dimensionar tu cluster:

  • Recolecta información sobre el tipo de consultas a realizar, tamaño de los datos, concurrencia esperada, etc.

  • Diseña tus tablas en base a las consultas que se vayan a realizar.

  • Dependiendo del tipo de consultas (sencillas, largas, complejas…), selecciona el tipo de instancia de Redshift (DC2, DS2 o RA3).

  • Teniendo en cuenta el tamaño del dataset, calcula el número nodos de tu cluster.

# of  Redshift nodes = (uncompressed data size) * 1.25 / (storage capacity of selected Redshift node type)  

« Para el cálculo del tamaño de almacenamiento, se recomienda tener además un margen mayor para realizar tareas de mantenimiento. »

  • Realizar pruebas de carga para comprobar el rendimiento.

  • En el caso de no funcionar adecuadamente, optimiza las queries modificando el diseño de las tablas incluso si fuera necesario.

  • Finalmente, si no fuera suficiente, itera hasta encontrar el dimensionamiento adecuado de nodos y tamaños.

4. No hacer uso de workload management (WLM)

Es bastante probable que vuestro caso de uso necesite que existan varias sesiones o usuarios que estén ejecutando consultas al mismo tiempo. En estos casos, algunas consultas pueden consumir recursos del clúster durante periodos de tiempo prolongados y afectar al rendimiento de las otras consultas. En esta situación, es posible que las consultas sencillas tendrán que esperar hasta que se complete las consultas más largas.

Mediante el uso de WLM, vamos a poder administrar la prioridad y capacidad de los diferentes tipos de ejecuciones creando diferente colas de ejecución.

Es posible configurar la WLM de Amazon Redshift para su ejecución de dos maneras diferentes:

  • Automatic WLM: la manera más recomendada es habilitar Amazon Redshift para que administre cómo se dividen los recursos para ejecutar consultas simultáneas con WLM automático. El usuario gestiona la prioridad de las colas y Amazon Redshift determina cuántas consultas se ejecutan simultáneamente y cuánta memoria se asigna a cada consulta enviada.
  • Manual WLM: alternativamente, se puede configurar de manera manual el uso de recursos de diferente colas. En tiempo de ejecución, se pueden enviar consultas a diferentes colas con diferentes parámetros de concurrencia y memoria gestionados por el usuario.


Cómo funciona WLM

Cuando un usuario ejecuta una consulta, WLM asigna la consulta a la primera cola coincidente, en función de las reglas de asignación de cola de WLM.

  • Si un usuario inició sesión como superusuario y ejecuta una consulta en el grupo de consultas con la etiqueta super usuario, la consulta se asigna a la cola superusuario.
  • Si un usuario pertenece a un grupo de usuarios de la lista o ejecuta una consulta dentro del grupo de consultas de la lista, la consulta se asigna a la primera cola coincidente.
  • Si una consulta no cumple con ningún criterio, la consulta se asigna a la cola predeterminada, que es la última cola definida en la configuración de WLM.

5. Desentenderse del mantenimiento

El mantenimiento de la base de datos es un término que usamos para describir un conjunto de tareas que se ejecutan con la intención de mejorar la base de datos. Existen rutinas destinadas a ayudar al rendimiento, liberar espacio en disco, verificar errores de datos, verificar fallos de hardware, actualizar estadísticas internas y muchas otras cosas oscuras (pero importantes).

En el caso de Redshift, se tiene la falsa sensación de que al ser un servicio totalmente administrado por Amazon no es necesario realizar ninguna. De esta manera creas el cluster y te olvidas de él. Aunque es cierto que AWS te facilita muchas tareas de administración (crear, parar, arrancar, destruir o realizar backups), esto no podría ser más erróneo.

Las tareas de mantenimiento más importantes que debes de llevar a cabo en Redshift son:

  • Motorización del sistema: es necesario que se monitorize el cluster 24/7 y realices revisiones periódicas para comprobar que el sistema funciona correctamente (sin consultas erróneas o bloqueos, espacio libre, tiempos de respuesta adecuados, etc). Además es necesario crear alarmas para poder anticiparse ante cualquier futura caída del servicio.
  • Compactación de las BBDD: Amazon Redshift no realiza todas las tareas de compactación en todas las situaciones automáticamente y otras veces vas a necesitar ejecutarlas de manera manual. Este proceso es denominado VACUUM y es necesario ejecutarlo manualmente para poder hacer uso de SORT KEYS de tipo INTERLEAVED. Este es un proceso bastante largo y costoso que va a tener que hacerlo a poder ser, en las ventanas de mantenimiento.
  • Integridad de los datos: como en toda carga de datos es necesario revisar que los procesos de ETL han funcionado adecuadamente. Redshift dispone de tablas de sistema como STV_LOAD_STATE en las que es posible encontrar información acerca del estado actual de las instrucciones COPY en curso. Debes de revisarlas a menudo para comprobar que no hay errores en la integridad de los datos.
  • Detección de consultas pesadas: Redshift monitoriza continuamente todas aquellas consultas que están tardando más de lo previsto y que podrían estar afectando negativamente el rendimiento del servicio. Para que puedas analizar e investigar esas consultas es posible encontrarlas en tablas de sistema como STL_ALERT_EVENT_LOG o a través de la misma consola web de AWS.
¿Quieres saber más de lo que ofrecemos y ver otros casos de éxito?
DESCUBRE BLUETAB
Share on twitter
Share on linkedin
Álvaro Santos
Senior Cloud Solution Architect​

Mi nombre es Álvaro Santos y ejerzo como Solution Architect desde hace más de 5 años. Estoy certificado en AWS, GCP, Apache Spark y alguna que otras más. Entré a formar parte en Bluetab en octubre de 2018 y desde entonces estoy involucrado en proyectos cloud de Banca y Energía y además participo como Cloud Master Partitioner. Soy un apasionado de las nuevas patrones distribuidos, Big Data, Open-source software y cualquier otra cosa de mundo IT que mole.

Deja un comentario

SOLUCIONES, SOMOS EXPERTOS

DATA STRATEGY
DATA FABRIC
AUGMENTED ANALYTICS

Te puede interesar

Introducción a los productos de HashiCorp

August 25, 2020
LEER MÁS

5 errores comunes en Redshift

December 15, 2020
LEER MÁS

Detección de Fraude Bancario con aprendizaje automático II

September 17, 2020
LEER MÁS

Hashicorp Boundary

December 3, 2020
LEER MÁS

Los Incentivos y el Desarrollo de Negocio en las Telecomunicaciones

October 9, 2020
LEER MÁS

Análisis de vulnerabilidades en contenedores con trivy

November 16, 2020
LEER MÁS

Filed Under: Blog, exportar

Hashicorp Boundary

December 3, 2020 by Bluetab Leave a Comment

Hashicorp Series Boundary

Share on twitter
Share on linkedin

Javier Pérez

DevOps Engineer

Javier Rodriguez

Cloud DevOps

Jorge de Diego

Cloud DevOps Engineer

After the last HashiConf Digital, the Cloud Practice wants to present you one of the main innovations that were presented: Boundary. In this post we are going to discuss what offers this new tool, why it is interesting, what we have found and how we have tested it.

What is Hashicorp Boundary?

Hashicorp Boundary is, as themselves claim, a tool that allows access any system using identity as a fundamental piece. What does this really mean?
Traditionally, when a user acquires the permission to access a remote service, he or she also gets explicit permission to the network where the service resides. However, Boundary, following the minimum privilege principle, provides us with an identity-based system for users who need access to applications or machines. For example, it is an easy way of access to a server via SSH using ephemeral keys as authentication method.

This means that Boundary limits what resources you can connect to and also manages the different permissions and accesses to resources with an authentication.

It is especially interesting because in the future it will be marked by the strong integration that it will have with other Hashicorp tools, especially Vault for credentials management and audit capabilities.

In case you are curious, Hashicorp has released the source code of Boundary which you have available at Github and the official documentation can be read on their website:
boundaryproject.

How have we tested Boundary?

BBased on an example project from Hashicorp, we have developed a small proof of concept that deploys Boundary in a hybrid-cloud scenario in AWS and GCP. Although the reference architecture does not said nothing about this design, we wanted to complete the picture and
set up a small multi-cloud stage to see how this new product.

The final architecture in broad terms is:

Once the infrastructure has been deployed and the application configured, we have tested connecting to the instances through SSH. All the source code is based on terraform 0.13 and you can find it in Bluetab-boundary-hybrid-architecture, where you will also find a detailed README that specifies the actions you have to follow to reproduce the environment, in particular:

  • Authentication with your user (previously configured) in Boundary. To accomplish this, you have to set the Boundary controllers endpoint and execute the following command: boundary authenticate.
  • Execute: boundary connect ssh with the required parameters to point to the selected target (this target represents one or more instances or endpoints)

In this particular scenario, the target is composed by two different machines:
one in AWS and one in GCP. If Boundary is not told which particular instance you want to access from that target, it will provide access to one of them randomly. Automatically, once you have selected the machine you want to access, Boundary will route the request to the appropriate worker, who has access to that machine.

What did we like?

  • The ease of configuration. Boundary knows exactly which worker has to address the request taking into account which service or machine is being requested.
    As the entire deployment (both infrastructure and application) has been done using terraform, the output of one deployment serves as the input of the other and everything is perfectly integrated.

  • It offers both graphic interface and CLI access. Despite being in a very early stage of development, the same binary includes (when configured as controller) a very clean graphical interface, in the same style as the rest of the Hashicorp tools. However, as not all functionality is currently implemented through the interface it is necessary to make configuration using the CLI.

What would we have liked to see?

  • Integration with Vault and indentity providers (IdPs) is still in the roadmap and until next versions it is not sure that it will be included.

  • The current management of the JWT token from the Boundary client to the control plane which involves installing a secret management tool.

What do we still need to test?

Considering the level of progress of the current product development, we would be missing for understanding and trying to:

  • Access management by modifying policies for different users.

  • Perform a deepest research on the components that manage resources (scopes, organizations, host sets, etc.)

Why do we think this product has great future?

Once the product has completed several phases in the roadmap that Hashicorp has established, it will greatly simplify resources access management through bastions in organizations. Access to instances can be managed simply by adding or modifying the permissions that a user has, without having to distribute ssh keys, perform manual operations on the machines, etc.

In summary, this product gives us a new way to manage access to different resources. Not only through SSH, but it will be a way to manage access through roles to machines, databases, portals, etc. minimizing the possible attack vector when permissions are given to contractors. In addition, it is presented as a free and open source tool, which will not only integrate very effectively if you have the Hashicorp ecosystem deployed, but will also work seamlessly without the rest of Hashicorp’s tools.

One More Thing…

We encountered a problem caused by the way in which the information about the network addresses of controllers and workers for subsequent communication was stored. After running our scenario with a workaround based on iptables we decided to open a issue on Github. In only one day, they solved the problem by updating their code. We downloaded the new version of the code, tested it and it worked perfectly. Point in favour for Hashicorp for the speed of response and the efficiency they demonstrated. In addition, recently it has been published a new release of Boundary, including this fix along with many other features Boundary v0.1.2.

¿Quieres saber más de lo que ofrecemos y ver otros casos de éxito?
DESCUBRE BLUETAB
Share on twitter
Share on linkedin

Deja un comentario

SOLUCIONES, SOMOS EXPERTOS

DATA STRATEGY
DATA FABRIC
AUGMENTED ANALYTICS

Te puede interesar

¿Cuánto vale tu cliente?

October 1, 2020
LEER MÁS

Bluetab se certifica como AWS Well Architected Partner Program

October 19, 2020
LEER MÁS

Los Incentivos y el Desarrollo de Negocio en las Telecomunicaciones

October 9, 2020
LEER MÁS

Bluetab se certifica como AWS Well Architected Partner Program

October 19, 2020
LEER MÁS

Tenemos Plan B

September 17, 2020
LEER MÁS

Cómo depurar una Lambda de AWS en local

October 8, 2020
LEER MÁS

Filed Under: Blog

Análisis de vulnerabilidades en contenedores con trivy

November 16, 2020 by Bluetab Leave a Comment

Análisis de vulnerabilidades en contenedores con trivy

Ángel Maroco

AWS Cloud Architect

Share on twitter
Share on linkedin

Dentro del marco de la seguridad en contenedores, la fase de construcción adquiere vital importancia debido a que debemos seleccionar la imagen base sobre la que ejecutarán las aplicaciones. El no disponer de mecanismos automáticos para el análisis de vulnerabilidades puede desembocar en entornos productivos con aplicaciones inseguras con los riesgos que ello conlleva.

En este artículo cubriremos el análisis de vulnerabilidades a través de la solución Trivy de Aqua Security, pero antes de comenzar, es preciso explicar en qué se basan este tipo de soluciones para identificar vulnerabilidades en las imágenes docker.

Introducción a CVE (Common Vulnerabilities and Exposures)

CVE es una lista de información mantenida por MITRE Corporation cuyo objetivo es centralizar el registro de vulnerabilidades de seguridad conocidas, en la que cada referencia tiene un número de identificación CVE-ID, descripción de la vulnerabilidad, que versiones del software están afectadas, posible solución al fallo (si existe) o como configurar para mitigar la vulnerabilidad y referencias a publicaciones o entradas de foros o blog donde se ha hecho pública la vulnerabilidad o se demuestra su explotación.

El CVE-ID ofrece una nomenclatura estándar para identificar de forma inequívoca una vulnerabilidad. Se clasifican en 5 tipologías, las cuales veremos en la sección Interpretación del análisis. Dichas tipologías son asignadas basándose en diferentes métricas (si tenéis curiosidad, consultad CVSS v3 Calculator)

CVE se ha convertido en el estándar para el registro de vulnerabilidades, por lo que la amplia mayoría de empresas de tecnología y particulares hacen uso de la misma.

Disponemos de múltiples canales para estar informados de todas las novedades referentes a vulnerabilidades: blog oficial, twitter, repositorio cvelist en github o LinkedIn.

Adicionalmente, si queréis información más detallada sobre una vulnerabilidad, podéis consultar la web del NIST, en concreto la NVD (National Vulnerability Database)

Os invitamos a buscar alguna de las siguientes vulnerabilidades críticas, es muy posible que de forma directa o indirecta os haya podido afectar. Os adelantamos que han sido de las más sonadas 🙂

  • CVE-2017-5753
  • CVE-2017-5754

Si detectas una vulnerabilidad, te animamos a registrarla a través del siguiente formulario

Aqua Security – Trivy

Trivy es una herramienta open source enfocada en la detección de vulnerabilidades en paquetes a nivel OS y ficheros de dependencias de distintitos lenguajes:

  • OS packages; (Alpine, Red Hat Universal Base Image, Red Hat Enterprise Linux, CentOS, Oracle Linux, Debian, Ubuntu, Amazon Linux, openSUSE Leap, SUSE Enterprise Linux, Photon OS and Distroless)

  • Application dependencies: (Bundler, Composer, Pipenv, Poetry, npm, yarn and Cargo)

Aqua Security, empresa especializada en el desarrollo de soluciones de seguridad, adquirió trivy en 2019. Junto a un amplio número de colaboradores, son los encargados del desarrollo y mantenimiento de la misma.

Instalación

Trivy dispone de instaladores para la mayor parte de sistemas Linux and macOS. Para nuestras pruebas vamos a utilizar el instalador genérico:

curl -sfL https://raw.githubusercontent.com/aquasecurity/trivy/master/contrib/install.sh | sudo sh -s -- -b /usr/local/bin 

Si no queremos persistir el binario en nuestro sistema, disponemos de una imagen docker:

docker run --rm -v /var/run/docker.sock:/var/run/docker.sock -v /tmp/trivycache:/root/.cache/ aquasec/trivy python:3.4-alpine 

Operaciones básicas

  • Imágenes locales

Trivy dispone de instaladores para la mayor parte de sistemas Linux and macOS. Para nuestras pruebas vamos a utilizar el instalador genérico:

#!/bin/bash
docker build -t cloud-practice/alpine:latest -<<EOF
FROM alpine:latest
RUN echo "hello world"
EOF

trivy image cloud-practice/alpine:latest 
  • Imágenes remotas
#!/bin/bash
trivy image python:3.4-alpine 
  • Proyectos locales:
    Permite analizar ficheros de dependencias (salidas):
    • Pipfile.lock: Python
    • package-lock_react.json: React
    • Gemfile_rails.lock: Rails
    • Gemfile.lock: Ruby
    • Dockerfile: Docker
    • composer_laravel.lock: PHP Lavarel
    • Cargo.lock: Rust
#!/bin/bash
git clone https://github.com/knqyf263/trivy-ci-test
trivy fs trivy-ci-test 
  • Repositorios públicos:
#!/bin/bash
trivy repo https://github.com/knqyf263/trivy-ci-test 
  • Repositorios de imágenes privados:
    • Amazon ECR (Elastic Container Registry)
    • Docker Hub
    • GCR (Google Container Registry)
    • Repositorios privados con BasicAuth
  • Cache database
    La base de datos de vulnerabilidades se aloja en github. Para evitar descargar dicha base de datos en cada operación de análisis, podemos utilizar el parámetro --cache-dir <dir>:
#!/bin/bash trivy –cache-dir .cache/trivy image python:3.4-alpine3.9 
  • Filtrar por criticidad
#!/bin/bash
trivy image --severity HIGH,CRITICAL ruby:2.4.0 
  • Filtrar vulnerabiliades no resueltas
#!/bin/bash
trivy image --ignore-unfixed ruby:2.4.0 
  • Especificar código de salida
    Esta opción en muy util en el proceso de integración continua, ya que podemos especificar que nuestro pipeline finalice con error cuando se encuentre vulnerabilidad de tipo critical pero las tipo medium y high finalicen correctamente.
#!/bin/bash
trivy image --exit-code 0 --severity MEDIUM,HIGH ruby:2.4.0
trivy image --exit-code 1 --severity CRITICAL ruby:2.4.0 
  • Ignorar vulnerabilidades específicas
    A través del fichero .trivyignore, podemos especificar aquellas CVEs que nos interesa descartar. Puede resultar útil si la imagen contiene una vulnerabilidad que no afecta a nuestro desarrollo.
#!/bin/bash
cat .trivyignore
# Accept the risk
CVE-2018-14618

# No impact in our settings
CVE-2019-1543 
  • Exportar salida en formato JSON:
    Esta opción es interesante si quieres automatizar un proceso antes una salida, visualizar los resultados en un front personalizado o persistir la salida con un formato estructurado.
#!/bin/bash
trivy image -f json -o results.json golang:1.12-alpine
cat results.json | jq 
  • Exportar salida en formato SARIF:
    Existe un estandar llamado SARIF (Static Analysis Results Interchange Format) que define el formato que deben tener las salidas cualquier herramienta de análisis de vulnerabilidades.
#!/bin/bash
wget https://raw.githubusercontent.com/aquasecurity/trivy/master/contrib/sarif.tpl
trivy image --format template --template "@sarif.tpl" -o report-golang.sarif  golang:1.12-alpine
cat report-golang.sarif   

VS Code dispone de la extensión sarif-viewer para la visualización de vulnerabilidades.

Procesos de integración contínua

Trivy dispone de plantillas para las principales soluciones de CI/CD:

  • GitHub Actions
  • Travis CI
  • CircleCI
  • GitLab CI
  • AWS CodePipeline
#!/bin/bash
$ cat .gitlab-ci.yml
stages:
  - test

trivy:
  stage: test
  image: docker:stable-git
  before_script:
    - docker build -t trivy-ci-test:${CI_COMMIT_REF_NAME} .
    - export VERSION=$(curl --silent "https://api.github.com/repos/aquasecurity/trivy/releases/latest" | grep '"tag_name":' | sed -E 's/.*"v([^"]+)".*/\1/')
    - wget https://github.com/aquasecurity/trivy/releases/download/v${VERSION}/trivy_${VERSION}_Linux-64bit.tar.gz
    - tar zxvf trivy_${VERSION}_Linux-64bit.tar.gz
  variables:
    DOCKER_DRIVER: overlay2
  allow_failure: true
  services:
    - docker:stable-dind
  script:
    - ./trivy --exit-code 0 --severity HIGH --no-progress --auto-refresh trivy-ci-test:${CI_COMMIT_REF_NAME}
    - ./trivy --exit-code 1 --severity CRITICAL --no-progress --auto-refresh trivy-ci-test:${CI_COMMIT_REF_NAME} 

Interpretación del análisis

#!/bin/bash
trivy image httpd:2.2-alpine
2020-10-24T09:46:43.186+0200    INFO    Need to update DB
2020-10-24T09:46:43.186+0200    INFO    Downloading DB...
18.63 MiB / 18.63 MiB [---------------------------------------------------------] 100.00% 8.78 MiB p/s 3s
2020-10-24T09:47:08.571+0200    INFO    Detecting Alpine vulnerabilities...
2020-10-24T09:47:08.573+0200    WARN    This OS version is no longer supported by the distribution: alpine 3.4.6
2020-10-24T09:47:08.573+0200    WARN    The vulnerability detection may be insufficient because security updates are not provided

httpd:2.2-alpine (alpine 3.4.6)
===============================
Total: 32 (UNKNOWN: 0, LOW: 0, MEDIUM: 15, HIGH: 14, CRITICAL: 3)

+-----------------------+------------------+----------+-------------------+------------------+--------------------------------+
|        LIBRARY        | VULNERABILITY ID | SEVERITY | INSTALLED VERSION |  FIXED VERSION   |             TITLE              |
+-----------------------+------------------+----------+-------------------+------------------+--------------------------------+
| libcrypto1.0          | CVE-2018-0732    | HIGH     | 1.0.2n-r0         | 1.0.2o-r1        | openssl: Malicious server can  |
|                       |                  |          |                   |                  | send large prime to client     |
|                       |                  |          |                   |                  | during DH(E) TLS...            |
+-----------------------+------------------+----------+-------------------+------------------+--------------------------------+
| postgresql-dev        | CVE-2018-1115    | CRITICAL | 9.5.10-r0         | 9.5.13-r0        | postgresql: Too-permissive     |
|                       |                  |          |                   |                  | access control list on         |
|                       |                  |          |                   |                  | function pg_logfile_rotate()   |
+-----------------------+------------------+----------+-------------------+------------------+--------------------------------+
| libssh2-1             | CVE-2019-17498   | LOW      | 1.8.0-2.1         |                  | libssh2: integer overflow in   |
|                       |                  |          |                   |                  | SSH_MSG_DISCONNECT logic in    |
|                       |                  |          |                   |                  | packet.c                       |
+-----------------------+------------------+----------+-------------------+------------------+--------------------------------+ 
  • Library: librería/paquete donde se ha identificado la vulnerabilidad.

  • Vulnerability ID: Identificador de vulnerabilidad (según estandar CVE).

  • Severity: existe una clasificación con 5 tipologías [fuente] las cuales tienen asignado una puntuación CVSS (Common Vulnerability Scoring System):

    • Critical (puntuación CVSS 9.0-10.0): fallos que podría aprovechar fácilmente un atacante no autenticado y llegar a comprometer el sistema (ejecución de código arbitrario) sin interacción por parte del usuario.

    • High (puntuación CVSS 7.0-8.9): fallos que podrían comprometer fácilmente la confidencialidad, integridad o disponibilidad de los recursos.

    • Medium (puntuación CVSS 4.0-6.9): fallos que, aún siendo más difíciles de aprovechar, pueden seguir comprometiendo la confidencialidad, integridad o disponibilidad de los recursos en determinadas circunstancias.

    • Low (puntuación CVSS 0.1-3.9): resto de problemas que producen un impacto de seguridad. Son los tipos de vulnerabilidades de los que se considera que su aprovechamiento exige unas circunstancias poco probables o que tendría consecuencias mínimas.

    • Unknow (puntuación CVSS 0.0): se otorga a vulnerabilidades que no tienen asignada puntuación.

  • Installed version: versión instalada en el sistema analizado.

  • Fixed version: versión en la que se resuelve el problema. Si no se informa la versión quiere decir que está pendiente de resolución.

  • Title: Descripción corta de la vulnerabilidad. Para más información, consultar NVD.

Ya sabemos interpretar a alto nivel la información que nos muestra el análisis. Ahora bien, ¿qué acciones debería tomar? En la sección Recomendaciones te damos alguna pista.

Recomendaciones

  • En esta sección describimos algunos aspectos más importantes dentro del ámbito de vulnerabilidades en contenedores:

    • Evitar (en la medida de lo posible) hacer uso de imágenes donde se hayan identificado vulnerabilidades critical y high

    • Incluir el análisis de imágenes en procesos de CI
      La seguridad en tu desarrollo no es opcional, automatiza tus pruebas y no dependas de procesos manuales.

    • Utilizar imágenes ligeras, menos exposiciones:
      Las imágenes tipo Alpine / BusyBox están construidas con el menor número de paquetes posible (la imagen base pesa 5MB), lo que se traduce en una reducción de vectores de ataque. Soportan múltiples arquitecturas y se actualizan con bastante frecuencia.
REPOSITORY  TAG     IMAGE ID      CREATED      SIZE
alpine      latest  961769676411  4 weeks ago  5.58MB
ubuntu      latest  2ca708c1c9cc  2 days ago   64.2MB
debian      latest  c2c03a296d23  9 days ago   114MB
centos      latest  67fa590cfc1c  4 weeks ago  202MB 
Si por algún motivo de dependencias no podéis customizar una imagen base de alpine, buscad imágenes tipo slim de proveedores de software confiables. Además del componente de seguridad, las personas que compartan red contigo lo agradecerán al no tener que bajar imágenes de 1GB
  • Obtener imágenes de repositorios oficiales: Lo recomendable es utilizar DockerHub y preferentemente imágenes de publishers oficiales. DockerHub y CVEs

  • Mantener actualizadas las imágenes En el siguiente ejemplo vemos un análisis sobre dos versiones diferentes de apache:

    Imagen publicada el 11/2018

httpd:2.2-alpine (alpine 3.4.6)
 Total: 32 (UNKNOWN: 0, LOW: 0, MEDIUM: 15, **HIGH: 14, CRITICAL: 3**) 

Imagen publicada el 01/2020

httpd:alpine (alpine 3.12.1)
 Total: 0 (UNKNOWN: 0, LOW: 0, MEDIUM: 0, **HIGH: 0, CRITICAL: 0**) 

Como podéis observar, si un desarrollo finalizó en 2018 y no se realizan tareas de mantenimiento, podría estar exponiendo un apache relativamente vulnerable. No es un problema derivado del uso de contenedores, pero debido a la versatilidad que nos proporciona docker para testar nuevas versiones de productos, ahora no tenemos excusa.

  • Especial atención a vulnerabilidades que afecten a la capa de aplicación:
    Según el estudio realizado por la compañía edgescan, el 19% de las vulnerabilidades detectadas en 2018 corresponden a capa 7 (Modelo OSI), destacando por encima de todos ataques de tipo XSS (Cross-site Scripting).

  • Seleccionar imágenes latest con especial cuidado:
    Aunque este consejo está muy relacionado con el uso de imágenes ligeras, consideramos hacer un inciso sobre las imágenes latest:

Imagen latest Apache (base alpine 3.12)

httpd:alpine (alpine 3.12.1)
 Total: 0 (UNKNOWN: 0, LOW: 0, MEDIUM: 0, HIGH: 0, CRITICAL: 0) 

Imagen latest Apache (base debian 10.6)

httpd:latest (debian 10.6)
 Total: 119 (UNKNOWN: 0, LOW: 87, MEDIUM: 10, HIGH: 22, CRITICAL: 0) 

En ambos casos estamos utilizando la misma versión de apache (2.4.46), la diferencia está en el número de vulnerabilidades críticas.
¿Quiere decir que la imagen basada en debian 10 convierte en vulnerable la aplicación que ejecuta en ese sistema? Puede que si o puede que no, hay que evaluar si las vulnerabilidades pueden comprometer nuestra aplicación. La recomendación es utilizar la imagen de alpine.

  • Evaluar el uso de imágenes docker distroless
    El concepto distroless es de Google y consiste en imágenes docker basadas en debian9/debian10, sin gestores de paquetes, shells ni utilidades. Las imágenes están enfocadas a lenguajes de programación (Java, Python, Golang, Node.js, dotnet y Rust), contiene exclusivamente lo necesario para ejecutar las aplicaciones. Al no disponer de gestores de paquetes, no puedes instalar tus propias dependencias, lo que se puede traducir en una gran ventaja y en otros casos, un gran obstáculo. Realizad pruebas y si encaja con los requisitos de vuestro proyecto, adelante, siempre es beneficioso disponer de alternativas. El mantenimiento corre a cuenta de Google, así que el aspecto de seguridad estará bien acotado.

Ecosistema de analizadores de vulnerabilidades para contenedores

En nuestro caso hemos utilizado trivy ya que se trata de una herramienta open source, fiable, estable y en continua evolución, pero disponemos de multitud de herramientas para el análisis de contenedores:

  • Clair
  • Snyk
  • Anchore Cloud
  • Docker Bench
  • Docker Scan
¿Quieres saber más de lo que ofrecemos y ver otros casos de éxito?
DESCUBRE BLUETAB
Share on twitter
Share on linkedin
Ángel Maroco
AWS Cloud Architect

Ángel Maroco llevo en el sector IT más de una década, iniciando mi carrera profesional con el desarrollo web, pasando una buena etapa en distintas plataformas informacionales en entornos bancarios y los últimos 5 años dedicado al diseño de soluciones en entornos AWS.

En la actualidad, compagino mi papel de arquitecto junto al de responsable de la Pŕactica Cloud /bluetab, cuya misión es impulsar la cultura Cloud dentro de la compañía.

Deja un comentario

SOLUCIONES, SOMOS EXPERTOS

DATA STRATEGY
DATA FABRIC
AUGMENTED ANALYTICS

Te puede interesar

¿Cuánto vale tu cliente?

October 1, 2020
LEER MÁS

Detección de Fraude Bancario con aprendizaje automático II

September 17, 2020
LEER MÁS

Bluetab se certifica como AWS Well Architected Partner Program

October 19, 2020
LEER MÁS

Conceptos básicos de AWS Glue

July 22, 2020
LEER MÁS

Introducción a los productos de HashiCorp

August 25, 2020
LEER MÁS

Espiando a tu kubernetes con kubewatch

September 14, 2020
LEER MÁS

Filed Under: Blog, Blog

Data-Drive Agriculture; Big Data, Cloud & AI aplicados

November 4, 2020 by Bluetab Leave a Comment

Detección de Fraude Bancario con aprendizaje automático II

José Carranceja

Director Operaciones América

Share on twitter
Share on linkedin
Hace unas semanas un cliente nos pidió que le contáramos como estaban posicionadas las tres big clouds en el mundo de la agricultura. Realmente no es una pregunta fácil, pero intentaré resumir algunos elementos que, desde mi experiencia, resultan relevantes acerca del estado de aplicación de las últimas tecnologías de datos en el sector. Un sector en el que la pandemia del coronavirus y su impacto en la escasez de trabajadores, han dado lugar a un aumento del interés por la inversión en robótica y la automatización.

En toda la cadena de valor del mercado agroalimentario hay realmente infinidad de soluciones de aplicación de tecnologías de analítica avanzada, empezando por soluciones cercanas al cliente final bajo el paraguas de los CRM y el Social Marketing, pasando por soluciones de automatización de procesos productivos bajo los ERP y la robotización de las operaciones, y por descontado soluciones de toda la cadena de logística en el ámbito del SCM, desde la optimización de rutas a la de activos en almacén. Pero son quizás menos conocidas y más específicas de agricultura, aquellas soluciones cercanas a los procesos iniciales en los cultivos y la producción de la materia prima alimentaria.

Probablemente este mercado se ha mantenido reticente a la implantación de grandes proyectos de transformación digital y por ello marginal para los grandes players, debido a la gran dispersión de los productores y su poca coordinación por iniciativas públicas. Pero aún con eso, marcas de la relevancia de Syngenta, DJI, Slantrange o John Deere representan en este momento ejemplos indudables de aplicación de las últimas tecnologías de analítica y datos en el sector.

En las fases productivas la combinación de sensores, drones, reconocimiento de imagen, termografía y espectrografía, vehículos autónomos y biotecnología han conseguido además de multiplicar las capacidades productivas, una drástica reducción de mano de obra, insumos químicos y uso de agua.

Actualmente además de los avances en sistemas de predicción meteorológica, los sistemas GPS o la fotografía satelital, los drones son una de las áreas de mayor desarrollo. Estas plataformas proporcionan información detallada sobre situación hidrológica, maduración de la cosecha o situación fitosanitaria. Las cámaras que montan actualmente plataformas Drone como DJI, permiten desde levantar geometrías tridimensionales del terreno, a identificar con precisión de centímetros donde aplicar agua o productos fitosanitarios y hasta el momento más adecuado para la cosecha de cada metro cuadrado. Todo ello mediante servicios disponibles en plataformas en la nube, utilizando algoritmos disponibles capaces de identificar número y tamaños de cosecha, o plagas específicas y su localización.

Tecnologías donde el procesamiento masivo de imágenes (gráficas, térmicas o espectrográficas) y la identificación de patrones son un elemento fundamental.

No hay que olvidar la gran evolución que los productos de origen químico o biológico están suponiendo. Syngenta a la cabeza de la producción de fertilizantes, semillas y productos fitosanitarios, promueve anualmente su Crop Challenge in Analytics en el que premia proyectos de analítica en todo el mundo para el desarrollo de sistemas eficientes y sostenibles.

Una característica relevante de este sector son los marketplaces, además de las soluciones cloud integradas que procesan las imágenes, proporcionan los resultados y generan las decisiones que conllevan, estos marketplaces provén también los modelos y algoritmos parametrizables para aplicarlos a tus datos. Slantrange a nivel internacional o Hemav en España son referentes de estas plataformas cloud integradas. Y plataformas como Keras o Caffe permiten no quebrarse la cabeza desarrollando algoritmos. Sencillamente hay que buscar los más adecuados, parametrizarlos para tu set de datos y ponerlos a competir para buscar el más eficiente. En Open AI están surgiendo nuevos modelos cada 18 meses.

Otro elemento fundamental son las plataformas de datos abiertos, desde meteorológicos, satelitales o geológicos a históricos en determinadas geografías. El cruce de estos con los datos propios, permiten desde predecir mejor fenómenos meteorológicos y su impacto en la maduración de la cosecha a predecir el futuro volumen de la misma y su valor en el mercado.

Finalmente, un elemento diferencial son los vehículos autónomos de empresas como John Deere que fabrica tractores que utilizan los mismos modelos de inteligencia artificial usados en coches autónomos tan sofisticados como el Waymo de Alphabet. Modelos de reconocimiento de imagen permiten colocar y medir las actuaciones de forma que llegan a reducirse en la aplicación de herbicidas o fertilizantes entre un 70 a un 90%. Hay que tener en cuenta que en condiciones normales aproximadamente un 50% de los fertilizantes se pierden en el ambiente.

En este contexto la revista 360 Market Updates en su informe de 2020, identifica para el mercado al que nomina como “Global Connected Agriculture”, una expectativa de crecimiento CAGR de 17.08% durante el periodo entre 2020 y 2024. Y los grandes players no son ajenos a esta perspectiva.

Intentando discriminar los principales actores en servicios cloud, según Gartner, en este momento son Google GCP, Amazon AWS y Microsoft Azure los lideres diferenciados tanto en infraestructura como en plataforma de analítica o BI. Pero es deficit identificar la más adecuada a un requerimiento genérico, incluso bajando a un nivel de detalle preliminar.

En nuestro análisis de las tres plataformas en el que hemos evaluado capacidades de extracción, integración y gobierno fundamentales, concluimos que las tres cuentan con servicios capaces de dar cobertura equivalente. Evidentemente las politicas de precio de todas se adaptan a los requerimientos de cada situación en los mismos términos de competitividad.

No obstante, bajando al terreno de las soluciones para el sector agroalimentario son AWS y Azure las que han desarrollado modelos de aproximación específicos. Ambos han desarrollado plataformas de integración para soluciones IoT, han integrando servicios para volcado de información de todo tipo de sensores, dispositivos o máquinas, y habilitando servicios para hacerlo tanto en streaming como en batch.

Tanto AWS como Azure cuentan con partners que apoyan los procesos de extracción de dichas plataformas IoT y aseguran las comunicaciones y la captación de los datos. Pero quizás Microsoft ha ido un paso más allá invirtiendo en partners con soluciones específicas end to end en el segment en el que son diferenciales en el sector. Un ejemplo de ello es Slantrange, que cubre el proceso completo que realizan los drones desde la generación de los planes de vuelo al procesamiento de las imagenes tanto termicas como termográficas y su explotación para la toma de decisions por los agricultores. Y en esa misma línea, Microsoft ha llegado a acuerdos con plataformas de drones líderes del mercado como DJI o AirMap y ha desarrollado una plataforma de simulación de vuelo Drone Flight Simulator 3D. Toda esta estrategia focalizada en el eslabón de origen de la cadena del negocio, le proporciona un paso adicional para la preparación de los datos previa al procesamiento en sus plataformas de inteligencia artificial.

El servicio Azure FarmBeats, permite la creación de un espacio especializado para el agricultor donde están integradas las capacidades de procesamiento de imagen de drones o satelital, así como algoritmos de análisis para la toma de decisions sobre cosechas.

Desde Bluetab vemos como la evolución de servicios de las tres plataformas están en un momento de extraordinaria evolución y las tres han entrado en una feroz carrera por asegurar que están a la altura de los servicios de sus mas cercanos competidores. Hoy en día cualquiera de las llamadas “killer application” como Kubernetes o kafka están disponibles en las tres y permiten unos niveles de integración de servicios, hasta ahora inpensables.  Por ello, en el análisis de la decision de la Plataforma, hay que incluir también otras variables de decisión importantes como son el nivel de implantación de la Plataforma en nuestro mercado local y la disponibilidad de recursos formados, la integración con nuestras plataformas actuales on premise o las políticas comerciales de cada una de ellas.

Podemos decir en términos generales, que actualmente la plataforma AWS lleva la delantera a sus competidores en lo que tiene que ver con posición de mercado, si bien ha tenido una pequeña reducción de su posición en el ultimo año. Y esto hace que en mercados como España o México nuestra percepción es que el número de recursos disponibles es tambien mayor.

Sin embargo, es claro que el nivel de preexistencia de soluciones Microsoft en el mercado corporativo y las facilidades de integración de toda su plataforma office con soluciones específicas como Power BI, hacen que la afinidad de uso para los usuarios posicione a Azure como la solución alternativa más demandada. Actualmente Power BI es una de las tres plataformas de explotación lideres conjuntamente con Tableau y Qlik.

Por otro lado, Google con GCP focaliza su estrategia en sus soluciones específicas de inteligencia artificial y machine learning como son sus soluciones de lenguaje natural o reconocimiento de imagen y sus plataformas tensorflow. Todo ello apoyado por la integración con sus plataformas de servicios bien conocidas como Maps o Adds. Y todo ello hace que su posición como tercer player esté afianzándose.

Finalmente hay que tener en cuenta dos puntos adicionales, el primero es que cada vez más el concepto multicloud es una realidad y herramientas como VM Ware permiten soluciones de gestion integradas para la coexistencia de diferentes soluciones con diferentes clouds. Por ello y este es el segundo punto, hay que evaluar los requerimientos específicos de cada servicio para valorar si alguna de ellas tiene un nivel de desarrollo superior. Así por ejemplo, en lo que tiene que ver con plataformas de gaming, Microsoft con Xbox parecería ser el lider, pero en este momento Lumberyard el motor de videjuegos y Twitch, ambos de AWS o Google Stream están entrando con fuerza. Y como en esto, en todos los segmentos, los tres competidores se reposicionan en pocos meses, por lo que las ventanas de diferenciación son a veces marginales.

Un mercado apasionante donde cada vez más las tres plataformas AWS, GCP y Azure, dificultan el acceso a otras como Alibaba, IBM y otros competidores, y profundizan en su posición generando oligopolios reales… pero este complejo asunto lo abordaremos en otra occasion.

¿Quieres saber más de lo que ofrecemos y ver otros casos de éxito?
DESCUBRE BLUETAB
Share on twitter
Share on linkedin
José Carranceja
Director Operaciones América

Actualmente COO de Bluetab para América, y ha desarrollado su carrera profesional en diferentes puestos de gestión internacional en áreas de ventas y consultoría en empresas como IBM, BT o Bankinter. Además, ha liderado iniciativas de emprendimiento como JC Consulting Ass. de consultoría tecnológica o Gisdron un start up de servicios drone. Es Arquitecto especialista en cálculo de estructuras y se ha formado en escuelas de posgrado como IESE, INSEAD o el TEC de Monterrey.

Deja un comentario

SOLUCIONES, SOMOS EXPERTOS

DATA STRATEGY
DATA FABRIC
AUGMENTED ANALYTICS

Te puede interesar

Introducción a los productos de HashiCorp

August 25, 2020
LEER MÁS

Espiando a tu kubernetes con kubewatch

September 14, 2020
LEER MÁS

¿Cuánto vale tu cliente?

October 1, 2020
LEER MÁS

Conceptos básicos de AWS Glue

July 22, 2020
LEER MÁS

Tenemos Plan B

September 17, 2020
LEER MÁS

Detección de Fraude Bancario con aprendizaje automático II

September 17, 2020
LEER MÁS

Filed Under: Blog, Uncategorized

Bluetab se certifica como AWS Well Architected Partner Program

October 19, 2020 by Bluetab Leave a Comment

Bluetab se certifica como AWS Well Architected Partner Program

Bluetab

Share on twitter
Share on linkedin
Dentro de nuestro camino de referentes especializados en Data Solutions /bluetab ha obtenido la certificación del AWS Well Architected Partner Program. Esto nos habilita para acompañar a nuestros clientes en el diseño y optimización de cargas de trabajo en base a las prácticas recomendadas de AWS. 
Nuestro ADN de Professional Excellence, nos acredita para establecer buenos hábitos de arquitectura, minimizar riesgos, y responder de manera ágil ante cambios que impacten en diseños, aplicaciones y cargas de trabajo.
Si eres cliente de AWS y necesitas crear soluciones de alta calidad o controlar el estado de tus cargas de trabajo, no lo dudes y contacta con nosotros en inquiries@bluetab.net.

¿Qué hacemos con WAPP?

Establecer medidas técnicas, tácticas y estratégicas a fin de aprovechar las oportunidades de mejora existentes en cada uno de los diferentes ámbitos

Optimización de costes
Identificar acciones recurrentes sustituible o piezas innecesarias que permitan reducir costes.

Seguridad
Establecer los riesgos de datos y sistemas

Eficiencia
Fijar los recursos necesarios para no incurrir en duplicidades, sobrecargas o cualquier otra ineficiencia.

Excelencia
Supervisar y controlar la ejecución para realizar mejoras continuas y mantener los demás pilares adecuadamente.

Fiabilidad
Visualizar los errores que afecten a cliente corrigiendo y recuperando de forma ágil

¿Quieres saber más de lo que ofrecemos y ver otros casos de éxito?
DESCUBRE BLUETAB
Share on twitter
Share on linkedin

Deja un comentario

SOLUCIONES, SOMOS EXPERTOS

DATA STRATEGY
DATA FABRIC
AUGMENTED ANALYTICS

Te puede interesar

Cómo depurar una Lambda de AWS en local

October 8, 2020
LEER MÁS

¿Cuánto vale tu cliente?

October 1, 2020
LEER MÁS

Bluetab se certifica como AWS Well Architected Partner Program

October 19, 2020
LEER MÁS

Introducción a los productos de HashiCorp

August 25, 2020
LEER MÁS

Espiando a tu kubernetes con kubewatch

September 14, 2020
LEER MÁS

Conceptos básicos de AWS Glue

July 22, 2020
LEER MÁS

Filed Under: Blog

Los Incentivos y el Desarrollo de Negocio en las Telecomunicaciones

October 9, 2020 by Bluetab Leave a Comment

Los incentivos y el desarrollo de negocio en las Telecomunicaciones

Bluetab

Share on twitter
Share on linkedin

El sector de las telecomunicaciones está cambiando más rápido que nunca. La creciente proliferación de competidores obliga a los operadores a considerar nuevas formas de ser relevantes para los clientes y las empresas. Muchas compañías han decidido convertirse en proveedores digitales de servicios, con el objetivo de satisfacer las necesidades de un consumidor cada vez más exigente.

Las compañías de telecomunicaciones han soportado una década de desafíos continuos, con la industria sometida a una serie de irrupciones que les empujan a innovar para no quedarse atrás. La revolución de los teléfonos inteligentes ha llevado al consumidor a demandar datos y conectividad ilimitada por encima de otros servicios.

Algunos estudios revelan que los principales retos a los que se enfrentarán las tele operadoras son la competencia disruptiva y creciente, la agilidad y la inversión, de las que se extraen cuatro mensajes clave para entender el futuro del sector:

1. La competencia disruptiva encabeza la lista de desafíos del sector

Plataformas como WhatsApp-Facebook, Google, Amazon han redefinido la experiencia del cliente ofreciendo servicios de mensajería instantánea, que han tenido un impacto directo en la demanda de servicios como los SMS, disminuyéndola radicalmente.

Además, la tendencia del mercado es ofrecer paquetes multiservicio y propiciar que el cliente los personalice según sus propias necesidades, llevando esto a fusiones, adquisiciones y asociaciones entre empresas, para poder ofrecer servicios cada vez más variados.

2. Apuesta por modelos comerciales digitales e innovación en la experiencia del cliente

Las grandes posibilidades que ofrece la digitalización la han convertido en el concepto al que aspiran la gran mayoría de compañías del sector. No es extraño que también en el sector de las telecomunicaciones se intente virar hacia un modelo de negocio digital.

Según el Observatorio Vodafone de la Empresa, un 53% de las empresas entienden la digitalización como el uso de las nuevas tecnologías en los procesos de su negocio y un 45% como el uso de nuevas tecnologías para mejorar el servicio al cliente.

3. El paisaje posterior a 2020 será transformado por el 5G

El 5G acaba de aterrizar en España, la nueva generación de telefonía móvil llamada a revolucionar no solo el mundo de las comunicaciones sino la industria del futuro. Los cuatro operadores nacionales ―Telefónica, Orange, Vodafone y MásMóvil― han lanzado ya los primeros servicios comerciales 5G, aunque solo en las ciudades más importantes, con una cobertura reducida y unas capacidades técnicas muy limitadas. En este arranque temprano ha influido también el cambio que ha supuesto la pandemia de la covid-19, que ha destapado la necesidad de estar comunicados en todo momento con buena calidad por el smartworking, educación digital, compras online y la explosión del streaming. España dispone de la red de fibra más potente de Europa, pero todavía hay regiones sin cobertura. Gracias a la apuesta total por la FTTH (fiber-to-the-home), nuestro país cuenta con una conexión estable que llega desde la central telefónica hasta casa de manera directa. Según datos del Consejo Europeo de Fibra hasta el hogar 2020, España cuenta con más instalaciones conectadas con fibra (10.261) que la suma de Francia, Alemania, Italia y Reino Unido.

Con estas necesidades de digitalización, las operadoras cobran un papel de máximo protagonismo.

Medidas a tener en cuenta

Conseguir esa digitalización tan ansiada no es un proceso fácil, y requiere un cambio de mentalidad organizacional, de estructura y de interacción.

El talento se cree que puede ser un elemento clave para la transformación digital, y defienden también que la falta de habilidades digitales es percibida como una barrera para conseguir dicha transformación, sus actos son otros. Pues, tan solo el 6% de los directivos creen que el crecimiento y la retención del talento son una prioridad estratégica.

Perspectiva de los trabajadores sobre su nivel de motivación laboral:

  • Un 40% se sienten infravalorados y poco apreciados por su empresa. Esta circunstancia aumenta la posibilidad de que los empleados busquen otro empleo que les devuelva la motivación laboral.
  • El 77% de los trabajadores reconoce que se implicaría más en su trabajo si se reconocieran sus logros dentro de la organización.
  • Más del 60% de las personas afirman que un programa de incentivos o beneficios sociales contribuye a no querer buscar otro trabajo. Para las empresas es un dato a tener en cuenta ya que se calcula que retener talento puede generar entre un 25% y un 85% de incremento en los beneficios de la empresa.

Perspectiva de las empresas sobre el nivel de motivación laboral de sus empleados:

  • El 56% de los responsables de gestión de personal manifiestan “estar preocupados” porque sus empleados abandonen la empresa.
  • El 89% de las empresas considera que la principal razón por la que sus trabajadores buscan otro empleo es que desean optar a un salario más elevado. Sin embargo, tan solo un 12% de los empleados que cambia de empresa gana más en su nuevo empleo, lo que demuestra que la retribución económica no es únicamente lo que motiva el cambio.
  • El 86% de las empresas ya tiene sistemas de incentivos o de reconocimiento para sus empleados.

Así, más allá de los cambios y las tendencias que se sucederán en este sector, las empresas de Telecomunicación deben intensificar la retención de talento y convertirlo en una prioridad para afrontar todos los retos a los que se enfrentan en su camino hacia la digitalización.

Una medida muy importante a la hora de retener y atraer talento, son los incentivos laborales. Los incentivos laborales, son recompensas que la empresa otorga al empleado por la consecución de unos objetivos determinados. De esta forma se aumenta la implicación, motivación, productividad y satisfacción profesional de los trabajadores.

Por ello, cada vez son más, las compañías del sector que deciden desarrollar un programa de incentivos laborales, en el que previamente, se han estudiado y planificado cuáles son los incentivos idóneos y que mejor se ajustan, en función de la empresa y el tipo de empleados, con el objetivo de motivar a sus trabajadores para que aumenten su producción y mejoren sus resultados laborales.

En el caso del sector de las comunicaciones, estas medidas supondrán también un aumento de las ventas y beneficios en la compañía. Dentro de este sector las ventas se realizan a través de distribuidores, agencias, comerciales internos y tiendas propias, dirigidas a clientes tanto particulares como a empresas. Por eso la importancia que se le otorga a la fuerza de ventas, lo que da lugar a comerciales más motivados y con mayores ganas de dar lo mejor de sí mismos día a día, llevando así a una mejora de beneficios para la empresa.

Además, estarán sujetos a incentivos todas las áreas asociadas a las ventas, departamentos que permiten, facilitan y se encargan de asegurar la salud de las ventas, así como de atención al cliente.

Para que un sistema de incentivos sea efectivo, es fundamental, que esté bien definido, bien comunicado, que sea entendible y que esté basado en unos objetivos medibles, cuantificables, explícitos y alcanzables.

Los incentivos laborales, pueden ser, económicos o no. Para el empleado tiene que ser algo que le suponga una recompensa o un premio a su esfuerzo. Solo así el plan de incentivos será eficaz.

Por último, una vez fijado el plan de incentivos, la empresa debe evaluarlo periódicamente porque en un entorno cambiante como el actual, los objetivos de compañía, las motivaciones de los empleados y el mercado variarán. Para adaptarse a los cambios en el mercado y a las distintas situaciones tanto internas como externas, deberá ir evolucionando en el tiempo.

¿Qué ventajas otorgan a las compañías telco los sistemas de incentivos?

Implantar un plan de incentivos en la empresa tiene muchos beneficios para los trabajadores, pero también para las compañías:

  • Mejora la productividad de los empleados
  • Atrae profesionales cualificados
  • Aumenta la motivación de los empleados
  • Evaluación de los resultados
  • Fomenta el trabajo en equipo

/bluetab en uno de nuestros cliente TELCO  ha desarrollado una herramienta interna de negocio de cálculo de incentivos para las distintas áreas asociadas a las ventas. En este caso, los incentivos laborales, son económicos y la evaluación de desempeño, asociada al cumplimiento de los objetivos, consiste en un porcentaje económico del salario. La consecución de una serie de objetivos, mide la contribución al crecimiento rentable de la compañía dentro de un período de tiempo.

Para dicho desarrollo del cálculo de los incentivos se tendrán en cuenta los siguientes factores:

  • Política: Definición y aprobación de la política de incentivos para los diferentes segmentos y canales de venta por parte del departamento de RRHH.
  • Objetivos: Reparto de objetivos de la compañía que se dividen en las diferentes áreas asociadas a la venta.
  • Performance: Desempeño de la fuerza de ventas y áreas asociadas a las mismas, en los períodos definidos previamente en la política.
  • Cálculo: Cálculo del desempeño y consecución de objetivos, de todos los perfiles incluidos en la política de incentivos.
  • Pago: Subida de pago a nómina de los incentivos correspondientes en función del rendimiento. Los pagos serán bimestrales, trimestrales, semestrales o anuales.

¿Cómo lo hacemos?

/bluetab desarrolla herramientas de seguimiento del cumplimiento de los objetivos y el cálculo de los incentivos. Esto permite a cada una de las personas relacionadas con la venta, a quienes les aplica este modelo, hacer seguimiento de sus resultados, así como a los diferentes departamentos relacionados con la decisión de los mismos, recursos humanos, directores de ventas, etc.

Para desarrollar este tipo de herramientas lo más importante es analizar todas las necesidades del cliente, recopilar toda la información necesaria para el cálculo de los incentivos y entender bien la política por completo. Analizamos y recopilamos todas las fuentes de datos necesarias para posteriormente integrarlas en un repositorio único.

Las diferentes fuentes de datos pueden ser ficheros en formato Excel, csv, txt, diferentes sistemas de información propios del cliente como Salesforce, herramientas de configuración de oferta, sistemas de bases de datos (Teradata, ORACLE, etc). Lo importante es adaptarse a cualquier entorno en el que trabaje el cliente.

Para la extracción de todas las fuentes de datos, de forma automática, habitualmente empleamos procesos programados en Python. A continuación, integramos todos los ficheros resultantes mediante procesos ETL, realizando todas las transformaciones necesarias y cargando los datos ya transformados, en un sistema de BBDD como único repositorio (por ejemplo Teradata)

Por último, conectamos la BBDD con una herramienta de visualización de datos, como por ejemplo Power BI. En dicha herramienta se implementa todos los cálculos de incentivos. Posteriormente se publican los cuadros de mando para compartirlo con los distintos usuarios proporcionando seguridad tanto a nivel de accesos como de protección de datos.

Como valor añadido, incluimos previsiones a futuro de dos formas diferentes. La primera basada en datos proporcionados por el cliente, reportados a su vez por la fuerza de ventas. La segunda, integrando algoritmos de análisis predictivo mediante el uso de Python, Anaconda, Spider, R,  que a partir de un histórico de los diferentes KPIs, permite estimar datos a futuro, con márgenes de error reducidos. Esto permite predecir a futuro los resultados de los incentivos.

Además, mediante el uso de parámetros, se podrán hacer simulaciones de los diferentes escenarios para el cálculo de los objetivos y consecución de los incentivos.

La herramienta de /bluetab desarrollada permitirá de una manera flexible, dinámica y ágil, a los departamentos afectados por los incentivos, realizar un seguimiento diario, semanal, mensual o anual de sus resultados. Así como a los departamentos implicados en las decisiones, la monitorización de los datos, les permitirá una mejora en la toma de decisiones futuras.

Beneficios aportados por /bluetab

  • Centralización de la información, posibilidad de hacer el cálculo y el seguimiento con una única herramienta.
  • Mayor periodicidad de actualización: Pasamos de una actualización en algunos casos mensual y semestral a diaria – semanal y en ocasiones real-time.
  • Reducción en un 63% de tiempo dedicado a tareas de cálculo manual.
  • Mayor trazabilidad y transparencia.
  • Escalabilidad y despersonalización de informes.
  • Reducción en un 11% de errores procedentes del manejo manual de múltiples fuentes diferentes. Calidad del dato
  • Inteligencia artificial simulando diferentes escenarios
  • Visualización dinámica y monitorización de la información
  • Mejora en la toma de decisiones a nivel de negocio
¿Quieres saber más de lo que ofrecemos y ver otros casos de éxito?
DESCUBRE BLUETAB
Share on twitter
Share on linkedin

Deja un comentario

SOLUCIONES, SOMOS EXPERTOS

DATA STRATEGY
DATA FABRIC
AUGMENTED ANALYTICS

Te puede interesar

Los Incentivos y el Desarrollo de Negocio en las Telecomunicaciones

October 9, 2020
LEER MÁS

5 errores comunes en Redshift

December 15, 2020
LEER MÁS

Cómo depurar una Lambda de AWS en local

October 8, 2020
LEER MÁS

5 errores comunes en Redshift

December 15, 2020
LEER MÁS

Hashicorp Boundary

December 3, 2020
LEER MÁS

Bluetab se certifica como AWS Well Architected Partner Program

October 19, 2020
LEER MÁS

Filed Under: Blog

  • Go to page 1
  • Go to page 2
  • Go to page 3
  • Go to Next Page »

Footer

LegalPrivacy Cookies policy
  • LinkedIn

Patron

Sponsor

© 2020 Bluetab Solutions Group, SL. All rights reserved.

  • Solutions
    • DATA STRATEGY
    • DATA FABRIC
    • AUGMENTED ANALYTICS
  • Software
    • TRUEDAT
    • FASTCAPTURE
    • TAILORED ENTERPRISE SW
  • About Us
  • Our Offices
  • Talent
  • Blog
  • Español