Más

¿Cientos de atributos causarán problemas de rendimiento en una capa de ArcGIS Server?

¿Cientos de atributos causarán problemas de rendimiento en una capa de ArcGIS Server?


Esto se relaciona con ArcGIS Server 10.0 SP1, con datos proporcionados desde una clase de entidad de polígono de geodatabase de archivos.

1) Por razones de rendimiento, ¿es una mala idea tener una clase de características con cientos de atributos?

2) ¿Es una mala idea crear un servicio de mapas de ArcGIS Server (que contenga cientos de atributos) a partir de esta clase de entidad?

3) ¿Hay alguna implicación en el rendimiento si creo un featureLayer en la API de JS y solo especifico los atributos que necesito actualmente?

por ejemplo, el servicio de mapas puede contener 500 atributos, pero defino mi capa de entidades usando

featureLayer.fields = [x, y, z]

Gracias por cualquier consejo. Por favor, avíseme si necesita más detalles.


En resumen, no es óptimo, pero puede que tampoco sea tan malo ...

En (3): siempre que especifique siempre los campos específicos que desea, el único "acierto" adicional debe estar en la solicitud inicial de los metadatos del servicio (que será un poco más grande debido a la gran cantidad de campos).

Si conoce el "conjunto" o el "tema" de los campos agrupados que usará su aplicación (de los 500), es posible que desee crear capas en el servicio de mapas que correspondan en consecuencia. Pero si su lista de campos es más dinámica, continúe como estaba pensando.

Sin embargo, en cuanto al rendimiento, primero concentraría su tiempo en optimizar / generalizar sus polígonos (ya que es probable que el tamaño de estos tenga un mayor impacto tanto en su tiempo de descarga, como en el tiempo de dibujo, carga, etc.). :)


Collar de telemetría GPS Fix Success y la verdad sobre los mapas

La tecnología de sistemas de posicionamiento global (GPS) ha mejorado la capacidad de los biólogos de la vida silvestre para obtener una mayor comprensión del comportamiento, los movimientos y el uso del espacio de la vida silvestre. Esto se logra ajustando a los animales salvajes, como los ciervos, con un collar equipado con una unidad de GPS. Mi investigación se basa en datos GPS representativos del venado cola negra colombiano (Odocoileus hemionus columbianus) en el oeste de Oregon para evaluar el uso del hábitat y el espacio. Los ciervos fueron capturados y monitoreados entre 2012 y 2017 en las Unidades de Manejo de Vida Silvestre de Alsea, Trask, Dixon e Indigo. Aunque esta tecnología ofrece numerosas oportunidades para responder preguntas de investigación, los datos del GPS están acompañados de errores en forma de arreglos perdidos o ubicaciones inexactas que deben corregirse antes de realizar análisis.

Figura 1. Un venado de cola negra colombiano echa un vistazo a sus captores que adornan un nuevo juego de crotales y un collar de telemetría GPS.

Corrección de sesgo de error de ubicación

Para tener en cuenta las ubicaciones imprecisas de los puntos de GPS (error de ubicación), las prácticas comunes de detección de datos utilizan valores de corte basados ​​en el tipo de punto de referencia (datos bidimensionales y tridimensionales 2D y 3D) y Dilución de precisión (DOP), que se registran con las coordenadas. obtenido por el collar GPS. La dilución de la precisión se puede considerar como un índice de calidad que indica la fuerza geométrica de una ubicación fija y es el resultado de la orientación del satélite. Cuanto más dispersos estén los satélites, más precisa será la ubicación. Se utilizan tres satélites para calcular los arreglos 2D, y los arreglos 3D necesitan al menos 4 satélites (Moen et al. 1996). Se recomienda que los datos 2D y 3D se traten de manera diferente porque el DOP se calcula de manera diferente para cada uno y tienen una precisión de ubicación variable (Frair et al.2010). Las ubicaciones que se prevé que sean más precisas son normalmente 3D y tienen valores de DOP bajos.

En el mundo de las ciencias de la información geográfica, los expertos generalmente se refieren a datos fijos con DOP menos ≤ 6 lo suficientemente buenos para la mayoría de las aplicaciones cartográficas (Bettinger n.d., Langley 1999, Anatum GeoMobile Solutions 2017). En el campo de la biología de la vida silvestre, muchos investigadores a menudo usan DOP como un indicador de qué ubicaciones son probablemente inexactas y deben eliminarse para reducir el sesgo. Aunque algunos estudios han demostrado una relación entre el error de ubicación, el DOP y la dimensión fija (Moen et al. 1996, D'Eon et al. 2002, D'eon y Delparte 2005, Lewis et al. 2007, Webb et al. 2013), otros estudios encontraron poca o ninguna relación entre los dos (Ironside et al. 2017).

Uno de mis objetivos era evaluar la relación en mis datos entre los tipos de datos DOP, 2D y 3D y el error de ubicación. Si no se pudiera derivar una relación clara de estas variables, entonces mi próximo paso sería utilizar uno de los cuatro métodos de detección comunes sugeridos por Lewis et al. 2007:

  1. Reclasifique todas las ubicaciones 2D a & # 8220 solución perdida & # 8221
  2. Reclasifique todas las ubicaciones 2D Y 3D con DOP & gt5 a & # 8220 arreglo perdido & # 8221
  3. Reclasifique todas las ubicaciones 2D Y 3D con DOP & gt7 a & # 8220 arreglo perdido & # 8221
  4. Reclasifique todos los 2D con DOP & gt5 Y 3D con DOP & gt10 a & # 8220 solución perdida & # 8221

Correcciones perdidas Corrección de sesgo

Además de seleccionar un método de detección, otra causa común de errores de GPS y errores de corrección es la obstrucción física entre el collar del GPS y los satélites, como la topografía o la vegetación. Una forma de corregir el sesgo inducido por el hábitat es colocar collares de GPS en ubicaciones fijas con características ambientales conocidas y tasas de éxito de corrección de GPS del modelo (FSR) en función de los atributos topográficos y vegetativos. Se dejaron fuera nueve collares GPS durante intervalos de 5-7 días en ubicaciones fijas (n = 53) en el área de estudio en febrero y marzo de 2020. Los horarios de reparación coincidieron con el mismo horario de reparación que se usó en los collares de ciervo. Las ubicaciones se eligieron específicamente para representar una variedad de terrenos y vegetación en el área de estudio.

Figura 2. Se dejaron fuera nueve collares de GPS durante intervalos de 5-7 días en ubicaciones fijas (n = 53) en el área de estudio en febrero y marzo de 2020. Las ubicaciones de los sitios de prueba son representativas de los atributos ambientales de Indigo, Dixon, Trask y Unidades de Manejo de Vida Silvestre de Alsea.

Las variables ambientales medidas a mano en cada sitio de prueba incluyen la cobertura del dosel, el aspecto, la pendiente y la categoría de cobertura del suelo. La cobertura del dosel se midió con un densitómetro esférico, el aspecto y la pendiente se midieron con una brújula con ángulo de inclinación y la cobertura del suelo se seleccionó utilizando descripciones que coincidían mejor con los alrededores de acuerdo con el Mapa de Hábitat del Estado de Oregón (Centro de Información de Biodiversidad de Oregón Instituto de Recursos Naturales, Universidad Estatal de Portland nd).

Estas variables también están disponibles a través de fuentes derivadas de ráster y los resultados de la prueba del collar estacionario se pueden utilizar para extrapolar a toda el área de estudio y crear un mapa predictivo donde cada píxel representa la probabilidad de adquirir una corrección (PREPARAR). Para corregir los análisis de selección de hábitat en busca de arreglos perdidos, se puede realizar un enfoque de ponderación de muestras utilizando el mapa de éxito del arreglo. La PREPARAR se estima para la ubicación GPS de cada ciervo, y la contribución de cada ubicación al modelo de selección de hábitat se pondera por el inverso del éxito de la corrección predicha (1 / PREPARAR (Frair et al. 2004, Hebblewhite et al. 2007). La ponderación de la muestra dará a las ubicaciones con una menor probabilidad de obtener una solución satisfactoria que tengan un mayor peso en el modelo de selección de hábitat en comparación con las ubicaciones con alto PREPARAR (Frair et al. 2010).

Figura 3. Los collares de GPS se desplegaron en ubicaciones estacionarias durante 5-7 días a la vez en diferentes hábitats. Los atributos ambientales como la pendiente, el aspecto, el cielo visible, la cubierta del dosel y el tipo de vegetación pueden interferir con la capacidad del collar GPS para contactar satélites. Esto puede provocar que no se obtenga una ubicación por completo o que se cometa un error y se recopilen los metros de ubicación incorrectos de las coordenadas reales.

Debido a que los análisis de selección de hábitat futuros se basan en la capacidad del mapa predictivo de éxito de arreglos para explicar la variación en los arreglos perdidos, es importante que el mapa refleje con precisión la topografía y la vegetación en el suelo. La prueba del collar estacionario también brinda una excelente oportunidad para "verificar la verdad sobre el terreno" de los datos ráster y ver qué tan bien coinciden los datos ráster con lo que hay en el terreno.

1.1 ¿Cuál es el mejor método de detección para usar en el conjunto de datos para eliminar tantos errores de ubicación como sea posible?

1.2 ¿Qué tan bien coinciden las covariables obtenidas de las mediciones terrestres con las covariables derivadas de la trama?

1.3 ¿Qué características vegetativas y topográficas predicen mejor las tasas promedio de éxito en la corrección del collar GPS?

1.4 ¿Existe una relación entre la escala de la cobertura del dosel derivada de los datos raster y las tasas de éxito de los arreglos, o las mediciones de la cobertura del dosel derivadas de las mediciones del suelo?

2.1 El error de ubicación se asociará con valores altos de DOP.

2.2 Los atributos ambientales medidos a mano desde el suelo serán similares a los mismos atributos extraídos de los datos ráster.

2.3 La disponibilidad del cielo y la cobertura del dosel tendrán la mayor influencia en el éxito de la corrección.

2.4 El éxito de la corrección y la relación de la cobertura del dosel medida desde el suelo variará según la escala de los datos ráster de cobertura del dosel.

3.1 Usé R-Studio (versión 3.6.1) para organizar, visualizar y filtrar los registros de localización de GPS. Los paquetes espaciales utilizados fueron: "sf", "sp" y "raster".

3.2 Usé R-Studio y los paquetes "sf", "sp" y "raster" para manipular datos de puntos y ráster y extraer datos de ráster.

3.3 Utilicé modelos de regresión mixta lineal generalizada para predecir las tasas de éxito de los arreglos en función de los atributos ambientales. Usé los paquetes "lme4" y "MuMIn" en R para realizar el modelado de regresión lineal y la selección del modelo.

3.4 ArcGIS, herramienta de "estadísticas focales" en Spatial Analyst R-Studio y paquetes "sf", "sp" y "raster" para apilar rásteres y extraer valores a puntos.

CovariableTipo de datosResolución de tramaOrigen rásterSoftwareHerramienta / Paquete
Cubierta del dosel%Medición de suelo y ráster30吚GNN
(Ohmann y Gregory 2002)
Pendiente °Medición de suelo y ráster10吆Derivado de ráster DEMArcGISPendiente (analista espacial)
Aspecto °Medición de suelo y ráster10吆Derivado de ráster DEMArcGISAspecto (analista espacial)
Cobertura terrestreMedición de suelo y Vector30吚Mapa de Hábitat en todo el estado de Oregon - 2018
(Instituto ORBIC de Recursos Naturales, Universidad Estatal de Portland 2018)
% De disponibilidad del cieloRáster solamente10吆Derivado de DEMArcGISFactor de vista del cielo (caja de herramientas de visualización de relieve)
Tabla 1. La mayoría de las variables explicativas para la prueba del collar estacionario fueron medidas en el suelo por los técnicos (cobertura del dosel, pendiente, aspecto, tipo de cobertura del suelo) pero la variable de disponibilidad del cielo se calculó en ArcGIS utilizando la herramienta Factor de vista del cielo de un ráster DEM .

Los datos de localización de GPS se descargaron de cada uno de los 9 collares de GPS e incluyen: latitud, longitud, fecha, hora, DOP y el número de satélites utilizados para obtener una ubicación. Calculé la diferencia entre la ubicación de cada sitio de prueba y las ubicaciones de corrección de GPS (error de ubicación) usando el comando "pointDistance" en el paquete "raster". Las coordenadas del sitio de prueba se obtuvieron a través de unidades GPS portátiles, y para evaluar qué tan precisas eran estas ubicaciones, calculé las ubicaciones de corrección promedio por sitio de prueba después de eliminar las ubicaciones con valores altos de DOP (2D con DOP y gt5 Y 3D con DOP y gt10). Descubrí que las distancias entre las coordenadas medias y las ubicaciones obtenidas del GPS de mano eran inferiores a 30 m, por lo que consideré que la ubicación del sitio de prueba original era lo suficientemente precisa como para ser considerada como la verdadera ubicación del sitio de prueba.

Extraje los valores del sitio de prueba de la cobertura del dosel, la disponibilidad del cielo, la pendiente y los rásteres de aspecto utilizando la función "extraer" en el paquete "ráster". Creé nuevas columnas para "corregir el éxito" (0/1) en función de declaraciones condicionales para datos no filtrados y examiné datos de cada uno de los 4 enfoques de detección. Las tasas de corrección de errores se calcularon por sitio de prueba y método de detección dividiendo el número de correcciones obtenidas con éxito por la cantidad total de correcciones intentadas. Para crear un conjunto de datos final, combiné los registros de corrección del GPS del sitio de prueba, el éxito de la corrección para los datos no analizados y analizados, y las características ambientales del sitio de prueba (valores derivados del suelo y valores derivados del ráster).

Antes de realizar análisis de regresión, busqué tendencias en las tasas de éxito de las correcciones diarias por sitio de prueba. Esto me permitió identificar si el clima influyó en el éxito de la solución.

Para evaluar la precisión de los datos ráster en comparación con las mediciones del hábitat adquiridas desde el suelo, realicé una correlación por pares de Pearson para identificar la relación de cada variable (| r | & gt 0,60).

Además, tenía curiosidad por encontrar la proporción de veces que las mediciones del suelo coincidían con los datos ráster. Para hacer esto, convertí todos los valores numéricos de cobertura del dosel, pendiente y aspecto a valores categóricos y sumé el número de veces que hubo una coincidencia. La cubierta del dosel se convirtió en grupos de 0-25%, 25-50%, 50-75% y 75-100%. La pendiente se convirtió en plana (& lt10 °), moderada (10 ° -20 °) y empinada (& gt20 °). El aspecto se convirtió en plano, norte, noreste, este, sureste, sur, suroeste, oeste y noroeste.

4.3 Regresión lineal de FSR de collar

Utilizando un marco de modelo lineal mixto generalizado, desarrollé modelos en competencia utilizando el sitio de prueba como unidad de muestra y la identificación del collar como la intersección aleatoria. Los modelos se consideraron competitivos si estaban dentro de 2 AICC unidades del modelo superior, y la selección del modelo se realizó en un enfoque de múltiples etapas. Cada etapa de comparación del modelo incluyó el modelo nulo, el modelo completo y los modelos univariados de las mediciones del suelo y los valores de la trama y sus formas cuadráticas y logarítmicas. Esta es una extensión de los esfuerzos de "verificación del terreno", pero también me permitió evaluar cada variable de una en una y determinar la mejor forma de cada variable, además de comparar directamente los valores de raster y terreno. Los modelos competitivos de cada etapa se llevaron a una comparación de modelos final para seleccionar un modelo superior final. Calculé el coeficiente de determinación condicional usando el comando "r.squaredGLMM" en el paquete "MuMIN".

4.4 Análisis de ventana móvil: cubierta de dosel

Los resultados (explicados a continuación) de la regresión lineal provocaron algunas preguntas más sobre la capa de cobertura del dosel. La cobertura de dosel del vecino más cercano gradiente (GNN) se deriva a través del análisis del vecino más cercano (Ohmann y Gregory 2002) y, por lo tanto, es más adecuado para análisis a escala de paisaje. Debido a que estoy interesado en la cobertura del dosel como un proceso puntual, tenía curiosidad por saber si alisar la cobertura del dosel a diferentes escalas alteraría su relación con el éxito de la corrección. Además, también me interesó si los valores de la cobertura del dosel a diferentes escalas estaban relacionados con las mediciones que obtuvimos desde el suelo.

Elegí arbitrariamente 6 tamaños de ventana diferentes en función de las distancias que me parecían razonables para probar usando una ventana móvil de estilo anular. Los radios interior y exterior tenían una distancia establecida de 2 celdas (20 m), y los únicos parámetros que cambiaban eran las distancias de los radios. Con esta técnica, cada celda focal se reclasifica como la cobertura de dosel promedio dentro de cada ventana móvil. Calculé las estadísticas focales medias en ArcGIS utilizando la herramienta "Estadísticas focales" en la caja de herramientas "Spatial Analyst". Después de crear nuevos datos ráster, exporté cada ráster a R-Studio, donde utilicé la herramienta "extraer" del paquete "ráster" para extraer la cubierta del dosel original y los nuevos valores medios derivados del análisis de la ventana móvil de las ubicaciones del sitio de prueba.

Evalué la relación de los valores estadísticos focales medios con los valores de cobertura del dosel medidos desde el suelo utilizando la correlación por pares de Pearson (| r | & gt0.60).

Para predecir la FSR como una función de la cobertura del dosel por sitio de prueba, utilicé un modelo mixto lineal generalizado con ID de collar como una intersección aleatoria porque el éxito de la reparación también puede variar entre collares individuales. Ejecuté 8 modelos univariados y utilicé el Criterio de información Akaike & # 8217s (AICC) para realizar la selección del modelo.

CanCov_s + (1 | CollarID), datos = CanCov.Scale.df)
m2 & lt- lmer (Tasa de éxito fija 3

CanCov1.3_s + (1 | CollarID), datos = CanCov.Scale.df)
m3 & lt- lmer (tasa de éxito fija 3

CanCov3.5_s + (1 | CollarID), datos = CanCov.Scale.df)
m4 & lt- lmer (Fix.uccess.Rate.3

CanCov5.7_s + (1 | CollarID), datos = CanCov.Scale.df)
m5 & lt- lmer (Fix.uccess.Rate.3

CanCov7.9_s + (1 | CollarID), datos = CanCov.Scale.df)
m6 & lt- lmer (Fix.uccess.Rate.3

CanCov9.11_s + (1 | CollarID), datos = CanCov.Scale.df)
m7 & lt- lmer (Fix.uccess.Rate.3

CanCov11.13_s + (1 | CollarID), datos = CanCov.Scale.df)
m8 & lt- lmer (Fix.uccess.Rate.3

CanCov.grnd + (1 | CollarID), datos = CanCov.Scale.df)
m.null = lmer (Fix.Success.Rate.3

Una ubicación estaba a casi 4000 m de distancia del sitio de prueba y se consideró un valor atípico y se eliminó de las estadísticas de resumen. El método 2 (eliminar todas las ubicaciones 2D y 3D con DOP & gt5) fue el enfoque más conservador y, aunque perdió la mayoría de los datos (22%) en comparación con los datos no filtrados y la tasa de corrección más baja, también tuvo los datos más precisos. El método 1 (eliminar todas las ubicaciones 2D) tuvo la menor proporción de ubicaciones dentro de los 30 m, la distancia promedio más alta desde el sitio de prueba hasta las coordenadas de localización del GPS, el DOP promedio más alto y una de las proporciones más altas de ubicaciones a más de 100 m de distancia del sitio de prueba . Aunque el método 4 (eliminar todas las correcciones 2D con DOP & gt5 y las correcciones 3D con DOP & gt10) retuvo la mayor cantidad de datos en comparación con los datos no analizados y tuvo la tasa de corrección más alta, también mantuvo algunas de las ubicaciones con errores de ubicación más grandes y tuvo el segundo DOP promedio más alto y error de ubicación. El método 3 (eliminar ubicaciones 2D y 3D con DOP & gt7) parece ser el mejor compromiso entre preservar el tamaño de la muestra (1547 ubicaciones en comparación con 1764) y eliminar la mayoría de las ubicaciones asociadas con un alto error de ubicación.

Figura 4. Los métodos de cribado corrigen la comparación con el error de ubicación por DOP para cada arreglo exitoso y agrupados por arreglos 2D y 3D. Arriba a la izquierda: Método 1: eliminar todas las correcciones 2D Arriba a la derecha: Método 2: eliminar todas las ubicaciones 2D Y 3D con DOP & gt5 Abajo a la izquierda: Método 3: eliminar todas las ubicaciones 2D y 3D con DOP & gt7 Abajo a la derecha: Método 4: eliminar todas las 2D con DOP & gt5 y 3D con DOP & gt10.

Datos no apantallados 1Método1 2Método2 3Método3 4Método 4 5
Pérdida de datos prop.0.000.050.220.120.04
Prop.Locs y lt30m0.780.790.830.820.80
Prop.Locs y gt100m0.030.020.010.010.02
Prop.Locs_2D0.050.000.000.000.04
Prop.Locs_3D0.951.001.001.000.96
DOP_avg3.993.953.113.433.61
DOP_min0.300.300.300.300.30
DOP_max23.6023.605.007.009.90
DOP_var6.185.960.821.532.37
DOP_SD2.492.440.911.241.54
LocError_avg25.7324.0419.3720.7322.39
LocError_min0.300.300.300.300.30
LocError_max598.40598.40285.90285.90327.70
LocError_var1538.361340.22480.56569.24712.19
LocError_SD39.2236.6121.9223.8626.69
FSR0.910.860.710.800.87
Tabla 2. Resultados del cribado utilizando los cuatro enfoques de cribado sugeridos por Lewis et al. 2007 en comparación con los datos no filtrados.
1 Datos sin filtrar: conjunto de datos original sin filtrar. 2 Método 1: reclasificar todas las ubicaciones 2D a & # 8220 corrección perdida ". 3 Método 2: reclasificar todas las ubicaciones 2D Y 3D con DOP & gt5 a & # 8220 solución perdida ". 4 Método 3: reclasificar todas las ubicaciones 2D Y 3D con DOP & gt7 a & # 8220 solución perdida ". 5 Método 4: reclasificar todo 2D con DOP & gt5 Y 3D con DOP & gt10 a & # 8220 corrección perdida & # 8221

Encontré diferencias entre las mediciones tomadas por los técnicos en el suelo y los valores derivados de los rásteres GIS para el aspecto y la cobertura del dosel, pero no tanto para la pendiente.

Figura 5. Diagramas de dispersión que muestran la tendencia general de FSR relacionada con los valores de la pendiente, el aspecto y la cobertura del dosel para las mediciones tomadas por los técnicos en el suelo y los valores derivados de los rásteres GIS. En general, las parcelas muestran una relación negativa con FSR y ambas formas de pendiente, una relación cuadrática con el aspecto y algunas relaciones ligeramente diferentes con ambas formas de cobertura del dosel.

El análisis de correlación por pares de Pearson mostró que, en general, no existe una correlación entre el suelo y las variables derivadas de la trama. La única variable cuyos orígenes de medición están relacionados fue la pendiente (| r | & gt0.72). La cubierta del dosel tenía una relación débil (| r | & gt0.58). Además, descubrí que la disponibilidad del cielo y la pendiente (ráster) estaban relacionadas y no se incluían juntas en el mismo modelo.

Aspecto (suelo)Pendiente (suelo)CanCov (tierra)Disponibilidad del cielo (raster)Aspecto (raster)Pendiente (raster)CanCov (trama)
Slope.grnd0.221.00-0.01-0.57-0.060.72-0.12
Extracto de pendiente0.140.720.00-0.77-0.091.00-0.12
Aspect.grnd1.000.22-0.01-0.010.310.140.13
CanCov.grnd-0.01-0.011.00-0.04-0.090.000.58
Aspecto.extracto0.31-0.06-0.090.161.00-0.090.01
Extracto de CanCov.0.13-0.120.580.170.01-0.121.00
Disponibilidad del cielo-0.01-0.57-0.041.000.16-0.770.17
Tabla 3. La correlación de Pearson entre todas las variables terrestres y derivadas de la trama muestra resultados decepcionantes. Las mediciones tomadas desde el suelo y de datos ráster generalmente no parecen estar relacionadas. La cubierta del dosel tenía una relación débil (| r | & gt0.58).

Para poner esto en contexto, los resultados de la comparación de verificación del terreno muestran que la proporción de veces que las mediciones del terreno y los valores ráster coincidieron también fue decepcionantemente baja. La cobertura del suelo tuvo un 36% de coincidencias, la cobertura de dosel coincidió el 9% del tiempo, la pendiente fue más alta con un 66% y el aspecto coincidió el 45% del tiempo.

5.3 Regresión lineal de FSR de collar

Ejecuté 5 conjuntos de modelos que constan de cada variable en su forma escalada, cuadrática y registrada, los modelos nulo y completo. Un sexto conjunto de modelos incluía una interacción entre el aspecto y la disponibilidad del cielo. No pude probar una interacción entre la pendiente y la disponibilidad del cielo porque estaban correlacionados (| r | & gt0.77). El conjunto de modelos final estaba compuesto por modelos competitivos de los primeros 6 conjuntos de modelos, e incluía las formas cuadráticas y registradas de cobertura de dosel medidas desde el suelo, y la forma registrada de disponibilidad de cielo. El modelo superior fue el tronco de la cubierta del dosel medido desde el suelo con un densitómetro esférico que sostenía el 76% del peso en el conjunto de modelos (R 2: 0,58).

AICcdeltapeso
m.g.CanCov.log-16.104500.757996
m.g.CanCov2-13.67382.4306950.224827
m.null-7.949668.1548770.012849
m.SkyAvail.log-5.773510.331040.004328
m.g. completo47.5037563.608291.17E-14
m.rast.full71.2982887.402827.95E-20
Tabla 4. La selección del modelo resulta del proceso final de selección del modelo de varias etapas. El tronco de la cubierta del dosel medido desde el suelo con un densitómetro esférico sostuvo el 76% del peso en el conjunto de modelos. La forma cuadrática de la misma variable tenía una puntuación delta AICc de 2,43, pero solo el 22% del peso del modelo.

CovariableEstimarSEIC del 95% (menor)IC del 95% (superior)
Interceptar (registro)1.900.311.282.50
CanCov.grnd (registro)-0.880.24-1.36 -0.39
Tabla 5. Tabla de coeficientes que muestra estimaciones del modelo superior (m.g.CanCov.log).

5.4 Análisis de ventana móvil: cubierta de dosel

Las distancias de las ventanas móviles que estaban más relacionadas con las mediciones del suelo de la cobertura del dosel fueron a distancias de 30-50 metros de distancia (| r | = 0,65) y 90-110 metros de distancia (| r | = 0,65 Tabla 6). Las distancias menos relacionadas fueron valores extraídos directamente de las coordenadas del sitio de prueba (| r | = 0.58).

Radios interioresRadios exterioresCorrelación por pares de Pearson
350.65
9110.65
570.63
130.62
11130.61
790.59
000.58
Tabla 6. Las estadísticas focales medias utilizando una ventana móvil en forma de "rosquilla" revelaron la relación de la cobertura del dosel derivada de las mediciones del suelo con la cobertura del dosel en diferentes escalas espaciales.

Los resultados de la sección 5.3 (Regresión lineal del collar FSR) respaldados por este paso adicional que se tomó para evaluar la influencia de la cobertura del dosel a diferentes escalas espaciales, en comparación con las mediciones del suelo. La forma lineal de la cubierta del dosel medida con un densitómetro sostuvo el 92% del peso en el conjunto de modelos, con el siguiente mejor modelo, el modelo nulo, a más de 5 unidades delta AIC del modelo superior (Tabla 7).

AICcdeltapeso
m8-13.738600.92032
m.null-7.949665.7889220.05092
m7-3.3703910.368190.005158
m1-3.1115910.626990.004532
m3-2.9924210.746160.00427
m6-2.8989910.839590.004075
m2-2.716511.022090.00372
m4-2.6657611.072820.003627
m5-2.5234411.215140.003378
Tabla 7. Las mediciones del suelo de cobertura de dosel superaron todas las escalas y formas de datos de cobertura de dosel raster.

6. Importancia: ¿Qué aprendió de sus resultados?

Descubrí que para los collares GPS Lotek 3300S en el oeste de Oregon, los mejores métodos de detección para reducir el error de ubicación presente en los datos eliminaron todas las correcciones 2D y 3D con DOP & gt7. Este enfoque fue el mejor compromiso entre conservar el tamaño de la muestra y eliminar la mayor parte del sesgo. Este ejercicio me abrió los ojos porque me dio la oportunidad de ver lo común que es que las ubicaciones GPS estén a cientos de metros de una ubicación estacionaria.

Después de eliminar todas las correcciones 2D y 3D con DOP & gt7, el error de ubicación promedio para cada ubicación de sitio de prueba en relación con la cubierta del dosel parece ser inferior a 30 metros, la resolución de la capa GNN (Figura 6). Entonces, incluso en la cobertura de dosel más alta, la distancia promedio de un punto fijo todavía está dentro de los límites espaciales de la capa de cobertura de dosel. El método de detección seleccionado parece haber logrado eliminar la mayoría de los valores atípicos.

Figura 6. El error de ubicación promedio por sitio de prueba de los datos examinados parece tener una relación positiva con la cobertura del dosel, sin embargo, todavía es menor de 30 m, que es la resolución espacial de mi capa de cobertura del dosel.

Muchos biólogos de la vida silvestre no tienen la oportunidad de abordar los errores de mapeo en su sitio de estudio. Y tengo que decir que tal vez la ignorancia sea una bendición en este caso. He demostrado que la cobertura del dosel y las medidas de aspecto tomadas desde el suelo y de los datos ráster no están relacionadas (| r | & lt0.60), que la cobertura terrestre, el aspecto y la cobertura del dosel no coinciden la mayoría de las veces con lo que está realmente en el terreno. La selección del modelo golpeó esta casa cuando los FSR se explicaron mejor en todos los casos, ya sea mediante mediciones desde el suelo o el modelo nulo. Esto muestra que, por el momento, el uso de la capa de cobertura de dosel GNN actual no reflejará con precisión el éxito de la corrección en el área de estudio. Esto destaca la necesidad de datos ráster fiables, precisos y accesibles.

6.3 Regresión lineal de FSR de collar

Me sorprendió un poco que la topografía no desempeñara un papel más importante en la influencia de FSR, pero la cobertura del dosel tiene sentido. Cuando se vuelve a transformar, la estimación registrada de -0,88 se vuelve positiva (0,41), lo que es confuso porque esperaría que FSR disminuya a medida que aumenta la cobertura del dosel.

Mi capacidad para crear un mapa predictivo para corregir las correcciones perdidas se basa en una capa ráster representativa de las entidades que explican mejor la variación en el éxito de las correcciones. Es importante incluir estos hallazgos como pesos de muestra en los análisis de selección de hábitat, y el ejercicio de identificar la magnitud del sesgo del GPS inducido por el hábitat no es muy común en el mundo de la ciencia de la vida silvestre.

Figura 7. Los datos examinados dieron como resultado un 20% de intentos fallidos de reparación. De ese 20%, la mayoría de las correcciones perdidas estaban en las categorías de cobertura de dosel alto (75-100%) y medio-alto (50-75%). No hubo mucha variación en la cobertura del dosel en general entre las soluciones exitosas.

6.4 Análisis de ventana móvil: cubierta de dosel

Tenía la esperanza de que la exploración del efecto de diferentes escalas espaciales en FSR y la relación con las verdaderas mediciones de cobertura de dosel traería buenas noticias sobre la utilidad de mis datos ráster de cobertura de dosel. En su lugar, reforcé que realmente no es tan útil para lo que necesito. Una alternativa al uso de la capa GNN sería usar lidar.

7. ¿Qué aprendí? Software.

En general, esta fue la primera oportunidad que tuve para practicar el uso de datos espaciales en R. Cuando me quedé atascado volví a usar ArcGIS, pero también hubo ocasiones en que usé una combinación de los dos. Ojalá pudiera haberme sumergido más profundamente en algunas técnicas de análisis espacial, pero el momento no coincidió con el lugar en el que me encuentro actualmente con mi tesis.

8. Estadísticas

Tuve la oportunidad de revisar mis conocimientos sobre regresión lineal y autocorrelación. Al hablar con mis compañeros de clase, tuve la oportunidad de pensar en otros sistemas a través de la lente de las tendencias y patrones espaciales y temporales.

Soluciones GeoMobile de Anatum. 2017. ¿Qué es PDOP? Y por qué es obsoleto. Base de conocimientos de Anatum GeoMobile Solutions. & lthttps: //www.agsgis.com/What-is-PDOP-And-Why-its-Obsolete_b_43.html>. Consultado el 31 de mayo de 2020.

Bettinger, P. n.d. Dilución de precisión: terminología GPS. Introducción al GPS. & lthttp: //introgps.uga.edu/course/Dilution_of_Precision.html? & gt. Consultado el 31 de mayo de 2020.

D’eon, R. G. y D. Delparte. 2005. Efectos de la posición y orientación del collar radioeléctrico en el rendimiento del collar radioeléctrico GPS y las implicaciones de la PDOP en la detección de datos. Journal of Applied Ecology 42: 383–388.

D’Eon, R. G., R. Serrouya, G. Smith y C. O. Kochanny. 2002. Error y sesgo de radiotelemetría GPS en terreno montañoso. Boletín de la Sociedad de Vida Silvestre (1973-2006) 30: 430–439.

Frair, J. L., J. Fieberg, M. Hebblewhite, F. Cagnacci, N. J. DeCesare y L. Pedrotti. 2010. Resolución de problemas de ubicaciones imprecisas y con sesgo de hábitat en análisis ecológicos utilizando datos de telemetría GPS. Transacciones filosóficas de la Royal Society B: Biological Sciences 365: 2187-2200.

Frair, J. L., S. E. Nielsen, E. H. Merrill, S. R. Lele, M. S. Boyce, R. H. M. Munro, G. B. Stenhouse y H. L. Beyer. 2004. Eliminando el sesgo del collar GPS en los estudios de selección de hábitat. Journal of Applied Ecology 41: 201–212.

Hebblewhite, M., M. Percy y E. H. Merrill. 2007. ¿Son iguales todos los collares del sistema de posicionamiento global? Corrección del sesgo inducido por el hábitat mediante tres marcas en las Montañas Rocosas de Canadá Central. Journal of Wildlife Management 71: 2026-2033.

Ironside, K. E., D. J. Mattson, T. R. Arundel y J. R. Hansen. 2017. ¿Es beneficiosa la detección de errores de ubicación por telemetría GPS? Wildlife Biology 2017. Junta Nórdica para la Investigación de la Vida Silvestre. & lthttps: //bioone.org/journals/Wildlife-Biology/volume-2017/issue-17/wlb.00229/Is-GPS-telemetry-location-error-screening-beneficial/10.2981/wlb.00229.full>. Consultado el 31 de mayo de 2020.

Langley, R. B. 1999. Dilución de precisión. GPS World 10: 52–59.

Lewis, J. S., J. L. Rachlow, E. O. Garton y L. A. Vierling. 2007. Efectos del hábitat en el rendimiento del collar GPS: uso de la detección de datos para reducir el error de ubicación. Journal of Applied Ecology 44: 663–671.

Ohmann, J. L. y M. J. Gregory. 2002. Mapeo predictivo de la composición y estructura del bosque con análisis de gradiente directo e imputación de vecino más cercano en la costa de Oregón, EE. UU. Canadian Journal of Forest Research 32: 725–741.

Centro de Información sobre Biodiversidad de Oregón Instituto de Recursos Naturales, Universidad Estatal de Portland. 2018. Oregon Statewide Habitat Map & # 8211 2018. Oregon Spatial Data Library. & lthttps: //spatialdata.oregonexplorer.info/geoportal/detailsid=4f271c43605a48f3b1edf89f35f0db29>. Consultado el 6 de junio de 2020.

Moen, R., J. Pastor, Y. Cohen y C. C. Schwartz. 1996. Efectos del movimiento de los alces y el uso del hábitat en el rendimiento del collar con GPS. The Journal of Wildlife Management 60: 659.

Centro de Información sobre Biodiversidad de Oregón Instituto de Recursos Naturales, Universidad Estatal de Portland. Dakota del Norte. Oregon Statewide Habitat Map & # 8211 2018. Oregon Spatial Data Library. & lthttps: //spatialdata.oregonexplorer.info/geoportal/detailsid=4f271c43605a48f3b1edf89f35f0db29>. Consultado el 6 de junio de 2020.

Webb, S. L., M. R. Dzialak, K. L. Kosciuch y J. B. Winstead. 2013. Selección de recursos invernales por venado bura en la frontera entre Wyoming y Colorado antes del desarrollo de la energía eólica. Ecología de pastizales y gestión de amplificadores 66: 419–427.


Introducción

Una demanda cada vez mayor de materias primas en las sociedades modernas y el agotamiento de los recursos ya conocidos resaltan la importancia de la exploración minera para encontrar nuevos depósitos. El modelado probabilístico que utiliza información digital, como datos de teledetección, geoquímicos, geofísicos y geológicos, es una herramienta útil para la exploración y la minería, ya que proporciona información de bajo costo y fácilmente disponible que respalda la toma de decisiones de exploración y desarrollo minero. Por lo tanto, los métodos nuevos y confiables basados ​​en SIG para predecir áreas prospectivas y definir objetivos de exploración serían un activo para la industria minera.

En los últimos años se han desarrollado muchos métodos geo-computacionales basados ​​en el conocimiento y basados ​​en datos para el mapeo del potencial mineral. Los enfoques impulsados ​​por el conocimiento requieren un conocimiento experto sobre las asociaciones espaciales entre las capas evidenciales y el tipo de depósito mineral buscado. Los pesos asignados a cada capa de evidencia espacial reflejan este conocimiento. Este tipo de enfoque es adecuado para regiones que no están bien exploradas, los llamados terrenos de exploración greenfield (Carranza y Hale 2003 Carranza y Laborte 2015). Por otro lado, los enfoques basados ​​en datos son apropiados para regiones abandonadas de moderada a bien exploradas, donde las empresas mineras están interesadas en identificar nuevos depósitos en la proximidad de depósitos conocidos o minas en operación (Carranza et al. 2008). En este escenario, los pesos asignados a las capas son asociaciones espaciales entre las capas evidenciales y los depósitos ya conocidos (Carranza y Laborte 2015).

Se ha utilizado una amplia selección de algoritmos para encontrar áreas favorables utilizando métodos basados ​​en el conocimiento, como las funciones de creencias evidenciales (p. Ej., Carranza et al. 2005 Tien Bui et al. 2012 Ford et al. 2016), lógica difusa (p. Ej., Knox- Robinson 2000, Nykänen et al.2008) o enfoques basados ​​en datos como ponderaciones de la evidencia (p. Ej., Chung y Agterberg 1980 Agterberg 1992a, b Tangestani y Moore 2001 Xiao et al.2015) y regresión logística (p. Ej., Reddy y Bonham-Carter 1991 Oh y Lee 2008) Actualmente, existe una tendencia hacia técnicas de aprendizaje automático como redes neuronales artificiales (por ejemplo, Singer y Kouda 1996 Porwal et al.2003), árboles de decisión (Reddy y Bonham-Carter 1991), bosque aleatorio (RF ) (Carranza y Laborte 2015 Rodriguez-Galiano et al.2015) y máquinas de vectores de soporte (SVM) (Zuo y Carranza 2011 Abedi et al.2012). Cada uno de estos algoritmos tiene ventajas y limitaciones. Los pesos de la evidencia, por ejemplo, ofrecen una implementación intuitiva y resistencia a la “maldición de la dimensionalidad” que surge en los problemas de clasificación cuando se trata de datos en espacios de alta dimensión (Bellman 2015). Además, los parámetros de un modelo lineal permiten interpretaciones geocientíficas (Harris y Pan 1999 Porwal et al. 2003). El peso de la evidencia, sin embargo, requiere muchas ocurrencias minerales conocidas para el entrenamiento y no es adecuado para áreas poco exploradas (Brown et al. 2000). Además, el supuesto de independencia condicional de los datos de entrada con respecto a los sitios de entrenamiento afecta la calidad de la predicción del algoritmo de pesos de evidencia (Porwal et al. 2003 Zuo y Carranza 2011 Andrada de Palomera et al. 2015). Los métodos más complejos como las redes neuronales artificiales pueden proporcionar una gran precisión, especialmente cuando las relaciones no son lineales (Brown et al. 2000 Zuo y Carranza 2011 Abedi et al. 2012). Sin embargo, la naturaleza de caja negra de los algoritmos, así como el tiempo y el rendimiento necesarios para estimar potencialmente muchos hiperparámetros, pueden verse como un inconveniente al aplicar estas técnicas (Rodríguez-Galiano et al. 2015).

A pesar de sus importantes ventajas y varios estudios prometedores en otros campos, como el mapeo de ecotopos (Chan y Paelinckx 2008), la clasificación de la cobertura del suelo (Ghimire et al. 2012) y la estimación de reservas de mineral, según el conocimiento de los autores, solo un artículo Cheng (2015), existe sobre el impulso en la exploración minera. En este artículo, se utilizó el impulso junto con los pesos de la evidencia para superar el problema de la independencia condicional (Cheng 2015). El objetivo del presente estudio es presentar y discutir un nuevo enfoque para el mapeo de prospectividad utilizando algoritmos de impulso. Implementamos estos métodos como cajas de herramientas de Python en la plataforma ArcGIS y realizamos varios experimentos con datos de exploración del Cinturón Ibérico de Piritas (IPB) en España para evaluar su precisión, rendimiento y robustez en comparación con otros enfoques de aprendizaje automático como SVM. La implementación dentro de la plataforma ArcGIS permite el uso de resultados en dispositivos móviles para verificar el terreno y, por lo tanto, proporciona un flujo de trabajo optimizado para la industria de la exploración. Esto se hace cargando los resultados del modelado en la nube o servidor de ArcGIS y luego accediendo a ellos usando ArcGIS Collector, que permite la adquisición de datos en el campo. En áreas sin cobertura móvil, también es posible trabajar sin conexión y los datos se pueden sincronizar una vez que haya cobertura nuevamente.


6 errores de cifrado que conducen a violaciones de datos

El cifrado se ha hecho famoso últimamente al ayudar a los malos a ocultar secretos a los buenos. Si las supercomputadoras más poderosas del mundo no pueden romper las leyes matemáticas del cifrado, ¿cómo pueden el FBI, la NSA y la CIA descifrar las comunicaciones terroristas que interceptan?

Pero hay una otra cara de esta pregunta que rara vez se discute:

Si el cifrado es tan irrompible, ¿por qué las empresas y los gobiernos siguen siendo pirateados?

Si los terroristas pueden descargar una aplicación de la tienda de aplicaciones que usa cifrado para proteger sus mensajes de chat de la NSA, ¿por qué no la Oficina de Administración de Personal de EE. UU., The Home Depot, Target, JPMorgan y Citi Bank (solo por nombrar algunos)? utilizar el mismo cifrado para proteger los datos de sus clientes de los piratas informáticos? ¿Por qué siguen ocurriendo estas violaciones de datos cuando se utiliza un cifrado irrompible? fácilmente disponibles?

La respuesta es simple: casi todo el mundo está haciendo mal el cifrado.

Ha habido una explosión de nuevas aplicaciones de salud, financieras y gubernamentales en los últimos años, lo que ha dado como resultado que se agreguen más y más criptografía a las aplicaciones de back-end. En la mayoría de los casos, este código criptográfico está implementado incorrectamente [1] , dejando a las organizaciones con una falsa sensación de seguridad que solo se hace evidente una vez que son pirateadas y acaban en los titulares.

Error n. ° 1: asumir que sus desarrolladores son expertos en seguridad

"Pero mi empresa es diferente", podría estar pensando. "Nuestros ingenieros son brillantes". Desafortunadamente, incluso los desarrolladores de software más brillantes suelen no expertos en seguridad. Los expertos en seguridad se encuentran principalmente en TI. Son administradores de sistemas, probadores de lápiz y CISO. no escribir código (a menos que cuente los scripts escritos para entrar en un sistema).

Los desarrolladores de software son realmente buenos para resolver las cosas, solo mire StackOverflow, una comunidad masiva de desarrolladores que se ayudan mutuamente a resolver problemas desafiantes. Por lo tanto, no es probable que admitan tener una experiencia limitada cuando se les asigne algo que no hayan hecho antes. "Puedo resolverlo", es un mantra común de un buen desarrollador de software. Debería saber ... He estado codificando desde que tenía ocho años y lo digo todo el tiempo.

Desafortunadamente, cuando se trata de implementar el cifrado correctamente, no tiene una segunda oportunidad. Si bien un error típico de un desarrollador puede causar un error en una página web, un error en su canal de seguridad de datos puede poner en riesgo todos sus datos confidenciales.Lo peor de todo es que no se enterará del error durante meses o incluso años hasta que su organización sea pirateada. Y para entonces, es demasiado tarde.

Error n. ° 2: creer que el cumplimiento normativo significa que está seguro

"Nuestra aplicación es compatible con PCI. Por lo tanto, nuestros datos están seguros", es otro concepto erróneo que conduce a violaciones de datos. Claro, HIPAA, PCI, CJIS y otras reglas de cumplimiento normativo requieren que sus datos confidenciales estén protegidos. Pero no entran en muchos detalles sobre cómo debes hacer eso. Algunos ni siquiera mencionan específicamente el cifrado.

Hay muchas formas de equivocarse en la seguridad de los datos y estas pautas normativas no le dan la mano para asegurarse de que lo haga bien. Peor aún, muchos equipos de desarrollo que agregan cifrado a su código lo abandonan una vez que logran la seguridad mínima necesaria para una marca de verificación regulatoria. Esta mentalidad de "marca de verificación" hacia la seguridad de los datos es peligrosa.

Error n. ° 3: confiar en los proveedores de la nube para proteger sus datos

Con el crecimiento de la computación en la nube, cada vez más aplicaciones del lado del servidor se han trasladado de salas de servidores a centros de datos repartidos por todo el mundo administrados por empresas como Amazon, Microsoft y Google. Estos gigantes tecnológicos están invirtiendo cientos de millones de dólares en ciberseguridad para posicionarse como “LA” nube segura. Todo esto lleva a muchas organizaciones a asumir que los datos almacenados por estos proveedores son férreos. Ésta es una suposición arriesgada.

La infraestructura física que impulsa a la mayoría de los proveedores de la nube es segura y algunos incluso ofrecen opciones de cifrado. Sin embargo, siempre recomiendan que los desarrolladores cifren sus datos confidenciales. antes de almacenándolo en la nube. Amazon Web Services (AWS) incluso incluye el siguiente diagrama para enfatizar que el cifrado de datos es responsabilidad del cliente, no de ellos:

Modelo de responsabilidad compartida de AWS (crédito: AWS)

Como puede ver, una gran cantidad de responsabilidades de seguridad de datos recae sobre usted. Y esto es cierto para cualquier proveedor de la nube.

Error n. ° 4: confiar en el cifrado de bajo nivel

La protección de sus datos confidenciales con soluciones de cifrado de bajo nivel, como el cifrado de discos o archivos, puede parecer una solución tentadora con un solo clic. Sin embargo, muchas organizaciones confían únicamente en estas soluciones, lo cual es francamente peligroso.

Para empezar, el cifrado de disco solo se activa cuando el servidor está apagado. Mientras el servidor está encendido, el sistema operativo descifra los datos confidenciales de cualquiera que haya iniciado sesión ... incluidos los malos.

Al subir un nivel al cifrado de archivos, se encuentra con una característica popular llamada Cifrado de datos transparente de SQL (TDE) que se utiliza para cifrar archivos de bases de datos de Microsoft y Oracle con un solo clic de un interruptor. Sin embargo, al igual que el cifrado de disco, esta característica de seguridad es completamente ignorada por un pirata informático que logra iniciar sesión en su base de datos. Solo el archivo que almacena su base de datos en la unidad física está encriptado, por lo que, a menos que Tom Cruise ingrese en rápel al centro de datos para robar su unidad física, esto no le brindará mucha protección.

Error n. ° 5: usar los modos y algoritmos de cifrado incorrectos

Eche un vistazo a esta lista de algoritmos criptográficos de Wikipedia. Ahora eche un vistazo a los diferentes modos de cifrado de bloques para elegir. Aquí hay una publicación de StackOverflow sobre qué modo usar con AES. Estamos teniendo diversión aún. El punto es que hay muchas variaciones entre las que un desarrollador puede elegir cuando se le pide que "cifre nuestros datos confidenciales, por favor".

Una pregunta común que recibo cuando le cuento a un desarrollador acerca de la plataforma de administración de claves y cifrado de Crypteron es, "¿no todos los marcos de aplicaciones vienen con una biblioteca de cifrado?" A veces solo les pido que echen un vistazo a la documentación de mcrypt, la biblioteca de cifrado de PHP. Spoiler: no es bonito. Hay mucha información engañosa en Internet y MUCHAS formas de equivocarse:

  • Usar números aleatorios que no son criptográficamente seguros (o, en el caso del hackeo de Sony PS3, un constante)
  • Uso del modo AES-ECB para datos de más de 128 bits
  • Reutilizar un vector de inicialización (IV) varias veces, lo que puede anular todo el proceso de cifrado.
  • Uso de cifrado determinista para hacer búsquedas de datos confidenciales sin factorizar ataques de diccionario.

Estos ejemplos son solo una pequeña instantánea de la gran cantidad de problemas de cifrado. Está bien si no los comprende, la mayoría de los desarrolladores tampoco.

Error n. ° 6: equivocarse en la gestión de claves

Dejé el mayor error para el final. No manejar correctamente la administración de claves es, sin duda, la forma más común en que los datos confidenciales terminan en manos de piratas informáticos, incluso si se cifraron correctamente. Esto equivale a comprar la mejor cerradura del mundo y luego dejar la llave debajo del felpudo. Si los piratas informáticos obtienen sus datos cifrados y su clave de cifrado, se acabó el juego. Repasemos algunas fallas en la administración de claves.

Guardar la llave debajo del tapete

Supongamos que todos sus datos confidenciales ahora están encriptados y firmados correctamente. ¿Dónde pones tu clave de cifrado? Algunas opciones comunes:

  • En la base de datos - MALO
  • En el sistema de archivos: MALO
  • En un archivo de configuración de la aplicación: MALO

No lo olvide, tenemos que asumir que los piratas informáticos ya han entrado en su base de datos y servidor de aplicaciones, por lo que no puede almacenar su clave allí. Pero la mayoría de los desarrolladores lo hacen.

Dejar la llave desprotegida

Incluso una vez que encuentre un lugar separado para almacenar la clave, todavía no ha terminado porque los piratas informáticos también pueden ingresar allí. Por lo tanto, debe cifrar su clave de cifrado con otro cifrado clave, normalmente llamada Clave de cifrado de clave (KEK), que luego debe almacenar en una ubicación completamente diferente. Para una seguridad aún mayor, puede ir un nivel más alto y proteger sus KEK con una clave de cifrado maestra y una clave de firma maestra. Los desarrolladores rara vez agregan tantas capas de cifrado. Pero deberían hacerlo.

Obteniendo la llave de forma insegura

Incluso con tres capas de cifrado que protegen sus datos, todavía existe el desafío de transferir la clave a su aplicación de forma segura. Idealmente, esto implica la autenticación entre su aplicación y el servidor de administración de claves, así como la entrega a través de una conexión cifrada. una cuarta capa de cifrado. También existen consideraciones de rendimiento, como almacenar en caché de forma segura la clave en la memoria, lo que puede ser complicado. Es fácil equivocarse con estas complejidades.

Usando la misma clave para todos sus datos

¿Utiliza la misma llave para su casa, su coche y su oficina? Por supuesto que no. Entonces, ¿por qué usaría una clave de cifrado para todos sus datos confidenciales? Debe dividir sus datos en varias particiones de seguridad, cada una con su propia clave de cifrado. Este es un desafío, ya que requiere que usted determine de manera inteligente qué clave buscar cada vez que cifra y descifra datos. Entonces, la mayoría de los desarrolladores omiten este paso.

Nunca cambiar la llave

Todo el mundo sabe que es una buena idea cambiar las cerraduras de vez en cuando y lo mismo ocurre con el cifrado. Esto se llama rotación de claves y no es trivial. Requiere mantener múltiples versiones de cada clave de cifrado y hacerla coincidir con la versión correspondiente de los datos cifrados. En ciertos casos, debe migrar sus datos existentes de la clave anterior a la clave nueva. que es aún más complicado. Nuevamente, la mayoría de los desarrolladores omiten este paso por completo y nunca cambian sus claves de cifrado.

Es posible una seguridad de datos sólida

Este artículo no está destinado a ser todo pesimismo. De hecho, es todo lo contrario. La gente está empezando a volverse insensible a todas las violaciones de datos que siguen ocurriendo. Existe una nueva sensación de que ser pirateado es inevitable y que ningún dato está seguro. Pero ese no es el caso. ES posible realizar el cifrado correctamente y disminuir drásticamente sus posibilidades de ser pirateado. Si aprendemos de nuestros errores, nos informamos sobre la seguridad de los datos y evitamos reinventar la rueda, el cifrado puede ser nuestro aliado más fuerte en la lucha contra los piratas informáticos.


Soluciones de creación de mapas y gráficos 10.4.1 parche 1 (escritorio | servidor)

Este parche está obsoleto. Todas las actualizaciones de Mapping and Charting Solutions 10.4.1 para (escritorio y servidor) se han incorporado en Mapping and Charting Solutions 10.4.1 parche 2.

Introducción

  • ArcGIS para la aviación
  • ArcGIS for Maritime: batimetría
  • ArcGIS for Maritime: gráficos
  • ArcGIS for Maritime: servidor
  • Mapeo de defensa de Esri
  • Mapeo de producción de Esri

Instalando

  1. Inicie sesión con una cuenta de administrador de Windows.
  2. Seleccione y descargue el archivo de cartografía y gráficos.
Parche 1 Suma de comprobación (Md5)
Escritorio MappingandCharting1041Patch1.msp B773856B00BF68147338544F50E2D392
Servidor MappingandChartingServer1041Patch1.msp 026F431B6BAEE8C7356F5FBA199183D2

Mejoras y problemas resueltos con este parche

    ArcGIS para la aviación
  • Se pueden crear características de anotación TFS88485 con un MapID nulo cuando se trabaja en un entorno multiusuario.
  • TFS88568 Actualiza la lógica para manejar variaciones en el nombre del campo RunwayDesignator.
  • TFS88703 Line Bypass y Cut Line fallan cuando se ejecutan en todas las funciones.
  • TFS88797 Agregue nuevas reglas basadas en puntos CGA en el directorio de instalación.
  • TFS88806 Necesita comprobar la dirección de la línea inversa al fusionar Airspace y Geoborder.
  • TFS89126 ChangeReporter puede fallar sin un error de memoria insuficiente cuando se ejecuta en conjuntos de datos más grandes (más de 20000 registros).
  • TFS89482 Cambie el mxddictionary en la salida del generador de secuencias de comandos de Python para que se ordene.
  • El importador de TFS89680 AIXM 5.1 necesita extraer el RepATCCode de los datos.
  • TFS89681 ATSRoute Calculator es lento después de que se agregaron las nuevas actualizaciones al algoritmo Vincenty.
  • TFS90028 Maneja arcbycenterpoint para sectores MSA.
  • TFS90129 La herramienta de punto de cambio devuelve un error .net para las rutas con un cambio en el segmento de inicio de la ruta.
    ArcGIS for Maritime: gráficos
  • BUG-000096683 La herramienta S-58 to Reviewer no puede procesar conjuntos de datos S-57 con ciertos nombres de agencias.
  • La extracción TFS87508 para MCSCL no filtra productos NO ENC en la exportación
  • El código TFS87736 en Exportar está cambiando y corrompiendo la referencia espacial en la geodatabase
  • TFS88304 DNC VPF: el exportador de VPF falla al encontrar datos de solo lectura
  • TFS88372 El número EDTN de la celda exportada no coincide con el EDTN en los metadatos PL después de la exportación del nuevo conjunto de datos
  • El exportador TFS88377 debe colocar las funciones en un orden específico en el archivo S-57
  • TFS88386 Los cambios en el orden en FFPT y SG3D generan 'ruido' innecesario en los ER
  • La secuencia transversal de pedido previo TFS89507 no cumple con las especificaciones S-57
  • TFS89920 La herramienta GP de creación de producto S-57 no extrae la agencia de la celda a los metadatos de la agencia productora de DSID en PL
    Mapeo de defensa de Esri
    Escritorio y servidor
  • BUG-000097106 La duración de los tics de minuto para los productos de mapas MTM50 y MTM100 debe ser de 5 mm.
  • TFS89061 Actualización de la herramienta Crear alturas puntuales para atribuir correctamente el campo ZVH cuando se utiliza un AOI personalizado.
  • TFS90135 Actualizar características divididas para proporcionar un mensaje de error si las características que se utilizan para dividir y las características de destino tienen una referencia espacial diferente.
  • TFS89499 Agregue una opción de valores y descripciones a GDB para exportar Shape.
  • TFS89232 Corrige la fuente del símbolo de cultivo en MGCP_TRD_4_2_MTM_Visual_Specification.
  • TFS90127 Actualización TM25, TM50 y TM100K Ferrocarril / intacto / ancho, estándar / electrificado / 1 vía (curva) PS-00382.
  • La herramienta GP TFS90015 SplitFeatures elimina los agujeros en el polígono de corte.
  • TFS89063 Refactor Create Rapid Graphic para proporcionar un mejor manejo e informes de errores.
  • TFS89686 Funciones divididas no crea un agujero cuando la función de corte está completamente contenida en la función que se está cortando.
  • TFS89746 Dividir entidades no crea vértices de intersección en la función de corte.
  • TFS89060 Elimina la dependencia de ReferenceData Cartography.gdb de la herramienta Crear bandas desde ráster.
    Escritorio
  • TFS88150 Actualizar el paso del flujo de trabajo MatchAOItoGrid para ejecutar en postgres.
  • TFS87802 Cree pasos de flujo de trabajo para definir los parámetros de filtro al usar el pago y la extracción.
  • TFS87894 La interfaz de usuario de pasos de la biblioteca de productos configurada debe ser predeterminada en un PL existente cuando se haya configurado uno en el esquema.
  • TFS88138 El campo CONNECTION_DIR en la longitud de la tabla JTX_QUEUE debe incrementarse.
  • TFS89374 Actualice el flujo de trabajo CheckExtendedPropertyStep para buscar la tabla de propiedades extendidas si usa un campo de identificación de trabajo con un nombre diferente a job_id.
  • TFS88961 Establecer configuración gráfica rápida no incluye TM25 en los flujos de trabajo.
  • TFS90190 Agregar nuevos tipos de trabajo para los flujos de trabajo Aplicar metadatos y Combinar producción.
  • TFS89062 Actualización de la herramienta Create Spot Heights GP para ejecutarse en un contorno seleccionado en una geodatabase personal.
    Servidor
  • TFS89493 Production Manager no debe evaluar trabajos con un 0% de finalización y solo 1 día transcurrido como retrasados.
  • TFS88815 Agrega capacidad de registro a POD.
    Mapeo de producción de Esri
    Escritorio y servidor
  • BUG-000096696 Data Reviewer: La herramienta Execute Reviewer Batch Job GP se está ejecutando muy lentamente con datos más grandes (1 millón de funciones).
  • TFS88449 Data Reviewer: Paso personalizado de WMX: Es posible que la comprobación de geometría en geometría no devuelva los resultados correctos si se selecciona la opción Solo características modificadas al utilizar el trabajo por lotes Ejecutar el revisor.
  • El elemento de tabla gráfica TFS86299 procedente de SDE bloquea ArcMap.
  • TFS88834 ProductionCustomStepsPostInstall.exe falla con el error Excepción de HRESULT: 0x800503F7 en la base de datos de Postgres.
  • TFS89675 Delete Dangles: No se respeta la comparación Compare_Features si se especifica un ángulo.
  • TFS90121 Generalizar funciones compartidas: falla con un error de SQL no válido. Escritorio
  • Nuevo: la herramienta de geoprocesamiento Disolución de producción agrega la capacidad de disolver entidades en la clase de entidad de entrada sin producir una nueva clase de entidad de salida.
  • BUG-000094428 Reciba 'El servidor WFS no está disponible actualmente' cuando intente agregar un WFS a través de HTTPS usando Agregar servidor WFS.
  • TFS88572 Node Renderer: no procesará cuelgan para la capa cuando el marco de datos se proyecta o no se proyecta
  • BUG-000097139 Al intentar agregar la conexión del servidor WFS mediante un servicio con cientos de capas, ArcMap se bloquea con un error de aplicación grave.

Actualizaciones de parches

Consulte la página Parches y Service Packs periódicamente para conocer la disponibilidad de parches adicionales. Aquí se publicará nueva información sobre este parche.

Cómo identificar qué productos ArcGIS están instalados

Para determinar qué productos ArcGIS están instalados, elija la versión adecuada de la utilidad PatchFinder para su entorno y ejecútela desde su equipo local. PatchFinder enumerará los productos, las correcciones urgentes y los parches instalados en su máquina local.

Obteniendo ayuda

Sitios nacionales, comuníquese con el Soporte técnico de Esri al 1-888-377-4575, si tiene alguna dificultad para instalar este parche. Sitios internacionales, póngase en contacto con su distribuidor de software Esri local.


8 Respuestas 8

Hay dos cuestiones importantes.

La primera es fácil: por lo general, no sabe qué tipo de recursos están disponibles en el lado del cliente. Si requiere 1.5GB para procesar algo, ¿realmente puede enviarlo a un navegador de cliente desconocido (IE, Safari, Opera, Firefox, etc.) en una plataforma de cliente desconocida? ¿Apreciará el cliente que su sistema lo persiga cuando lo abrume?

El segundo es más arquitectónico: ¿qué capas desea exponer al mundo exterior? La mayoría estaría de acuerdo en que es increíblemente arriesgado exponer su capa de datos. ¿Qué hay de su capa de servicio? ¿De verdad quieres transmitir esa lógica? Si lo hace, ¿también está exponiendo los puntos de entrada a su capa de datos? Si mantiene el lado del servidor de la capa de servicio, ¿qué queda? La interfaz de usuario, ¿verdad? Consulte la razón 1 sobre las consideraciones sobre cuánto de eso vive en el servidor y cuánto en el cliente.

Lo primero y más importante es Seguridad. Exponga toda su lógica al cliente y es un juego justo para los piratas informáticos y los exploits.

Todo lo que tenga un valor percibido no durará 5 minutos, especialmente el valor monetario, y será engañado o pirateado o explotado y dañará su sistema bastante gravemente. Incluso si tiene poco o ningún valor monetario, hay una clase de personas que lo piratearán solo para romper su sistema porque están aburridos.

Lado del cliente frente al lado del servidor

El procesamiento del lado del cliente está en línea con los estándares REST más populares, así como con MVC, en oposición a los enfoques basados ​​en páginas y SOAP. Con el surgimiento de estas tendencias y el enfoque en AJAX y Html-RIA, las secuencias de comandos del lado del cliente están en aumento y son más populares; sin embargo, debido a las preocupaciones de seguridad y la capacidad del cliente, las secuencias de comandos del lado del cliente tienen un nicho particular y no deben usarse para todo.

Si un gran segmento de su público objetivo serán usuarios móviles, el procesamiento pesado debe dejarse en manos del servidor.

Consistencia entre navegadores

Los estándares web han recorrido un largo camino y esto puede no ser una gran preocupación, pero todos los desarrolladores web saben que IE 6, 7 y 8 y, a veces, Safari pueden actuar de manera extraña en el lado del cliente; es posible que ciertas funciones no se ejecuten restricciones de seguridad y otros debido a estándares no implementados. También es importante tener en cuenta que el usuario final puede configurar un navegador para tener ciertas restricciones o incluso desactivar completamente el procesamiento del lado del cliente (¡sin javascript!). Si la coherencia es un requisito para el 100% de los usuarios (y especialmente si está haciendo algo poco ortodoxo), el lado del servidor es lo más importante.

Cualquier manipulación de datos que desee proteger debe realizarse en el servidor. Cualquier dato que se procese en el lado del cliente está absolutamente abierto a la manipulación. Por ejemplo, si tiene una función javascript que procesa cierta información que luego se vuelve a publicar en el sistema, sería muy fácil manipular el resultado justo antes de que se publique, incluso si tiene una seguridad de back-end ejemplar.

El procesamiento del lado del cliente se deja para la interfaz de usuario y la creación de aplicaciones de Internet enriquecidas (RIA). Se utiliza para crear animaciones, efectos, interacciones del usuario, así como para cargar contenido dinámicamente a través de llamadas AJAX en lugar de volver a cargar una página completa.

Principalmente será una duplicación de esfuerzos. Lo más probable es que los datos del cliente se verifiquen y procesen nuevamente en el nivel del servidor.

El servidor no puede asumir que su cliente rico / robusto envió los datos, por lo que con cualquier dato que se envíe, el servidor debe validarlo y procesarlo. Entonces tiene sentido ponerlo ahí.

Sin embargo, creo que se puede hacer algo de lógica a nivel de cliente para una mejor experiencia de interfaz de usuario.

Tienes razón, ¿por qué enviar datos al servidor si no está completo o es incorrecto? Es fácil verificar los campos obligatorios o teléfonos o direcciones de correo electrónico con el formato correcto. Nunca me gustó enviar un formulario y luego esperar 5 segundos para decirme que olvidé ingresar un campo. Ese tipo de procesamiento, claro, hágalo en el cliente y asegúrese de que sea correcto y use la lógica del lado del cliente para una respuesta rápida al usuario. Como ha señalado, un efecto secundario adicional sería que su servidor tendría que lidiar con menos solicitudes de datos incorrectos. PERO, el servidor todavía tiene que validar también, por lo que está duplicando la lógica. Pero sus usuarios estarán más felices.

Aquí hay una línea muy fina. La lógica de validación simple está bien, la lógica empresarial central no está bien.

En primer lugar, debe comprender la arquitectura de las aplicaciones web, la mayoría, si no todas, son de 3 niveles:

a) Cliente / Presentación: HTML y Javascript, puede contener ActiveX / Flash / Java Applets / Silverlight.Me arriesgaré y agregaré aplicaciones móviles nativas que se comunican con un servidor backend. Básicamente, la función de esta capa es proporcionar una interfaz para que el usuario del sistema interactúe con ella.

b) Lógica empresarial: PHP / RoR / Java donde se recopilan, procesan y almacenan los datos del cliente y donde las solicitudes de datos del cliente se procesan y se envían de vuelta al cliente

c) Backend Data Store: proporciona almacenamiento persistente para la información del sistema.

Entonces, ¿dónde se realiza la validación, en todas las capas? ¿Por qué?

a) Lado del cliente: asegúrese de que el usuario ingrese los datos correctos, los campos obligatorios, etc.

b) Lógica empresarial: filtrar, desinfectar y validar los datos del cliente. Ejecute reglas comerciales más complejas para garantizar que los datos estén bien formados para su almacenamiento. Parte de la validación realizada en el front-end se repite aquí, debido al hecho de que puede haber diferentes clientes, tome por ejemplo los navegadores, el Javascript se puede deshabilitar. También puede aceptar datos de diferentes fuentes a través de API, por ejemplo, por lo que todo debe ser validado.

c) Almacenamiento de datos backend: las restricciones garantizan que los datos estén bien formados para su almacenamiento y recuperación posterior.

Entonces, ¿dónde enfoca sus esfuerzos de validación, usa cada capa para realizar la validación que más le convenga y deja reglas más complejas para la capa que puede manejarla?

Una gran parte es mantener su procesamiento cerca de sus datos. Si tiene cientos de GB de datos, obviamente no se los enviará a un cliente. Con el aumento de las velocidades de acceso a los datos, esto se está volviendo un problema menor, pero si tiene un sitio de Big Data, aún desea hacer tanto filtrado y reducción en el servidor como sea posible antes de enviarlo.

Cuando crea su comportamiento completamente en el lado del cliente (por ejemplo, con Javascript), el SEO puede convertirse en un problema.

Las soluciones web que mantienen mucho en el lado del servidor pueden mantener más fácilmente contenido específico publicado en una URL específica (generalmente RESTful), de una manera que sea visible para los motores de búsqueda.

Esto también significa que un visitante puede marcar una página específica. ¿Lo has probado en Facebook?

Esto se puede resolver, pero generalmente está integrado en aplicaciones que hacen mucho en el servidor (RAILS, WordPress, etc.), mientras que si está construyendo, por ejemplo, REACT, tendrá que pasar por el aro.

La razón es estabilidad.

En el lado del servidor, puedo elegir componentes estables. Por lo general, esto significa que elijo Java y un montón de bibliotecas cuidadosamente seleccionadas como FreeMarker. No hace falta decir que todas las bibliotecas, excepto las bibliotecas estándar de Java, se tratan como desechables, por lo que accedo a las bibliotecas externas a través de un contenedor de fabricación propia. Esto significa que puedo cambiar fácilmente de una biblioteca a otra si surge el requisito.

Siempre que actualizo Java a una nueva versión, generalmente funciona bien porque Java es un componente extremadamente estable incluso en las principales actualizaciones de versiones. Y también, todos los servidores que tengo ejecutan la misma versión de Java. No todos los clientes ejecutan la misma implementación de JavaScript.

Del lado del cliente, no puedo elegir componentes estables. Los fabricantes de navegadores me obligarán a elegir JavaScript, un lenguaje que no me gusta particularmente, pero que me veo obligado a usar. (Y no me hables de lenguajes que se compilan en JavaScript, ¡son horribles!) La implementación de JavaScript de cada navegador es diferente. Esto significa que es un infierno probar mi producto con todas las versiones de navegador compatibles.

¿Mi solución? Realizo todo el procesamiento que puedo en el lado del servidor, y el lado del cliente es solo un contenedor ligero que envía datos al servidor y recibe datos del servidor en forma de fragmentos JSON y HTML. Evite el uso de XML JSON en su lugar.

No hago plantillas del lado del cliente. Presto el contenido en el servidor a un fragmento HTML que luego asigno usando el atributo .innerHTML a varios elementos de marcador de posición en el lado del cliente. Esto mantiene la pila de tecnología lo más simple posible, porque no necesito dos motores de plantilla (uno de Java y uno de JavaScript).

El inconveniente es, obviamente, que la latencia de la velocidad de la luz de medio segundo de latencia no es infrecuente entre continentes.

Tenga en cuenta que sus clientes en estos días pueden ser teléfonos inteligentes. Los teléfonos inteligentes tienen una duración limitada de la batería, por lo que si está realizando un cálculo pesado, es mejor descargarlo en sus servidores. Sin embargo, las cosas simples pueden ser más eficientes energéticamente cuando se realizan en el lado del cliente porque entonces puede evitar el acceso por radio. Pero el argumento principal, la estabilidad, puede significar que en realidad puede tener sentido descargar incluso cálculos simples al servidor.


Rediseño de la gestión de la congestión en Ethernet sin pérdidas

Wenxue Cheng y Kun Qian, Universidad de Tsinghua y Centro Nacional de Investigación de Ciencia y Tecnología de la Información de Beijing (BNRist) Wanchun Jiang, Universidad Central Sur Tong Zhang, Universidad de Tsinghua, Centro Nacional de Investigación de Ciencia y Tecnología de la Información de Beijing (BNRist) y Universidad de Aeronáutica y Astronáutica de Nanjing Fengyuan Ren, Universidad de Tsinghua y Centro Nacional de Investigación de Ciencia y Tecnología de la Información de Beijing (BNRist)

La Ethernet sin pérdidas es atractiva para los centros de datos y los sistemas de clúster, pero varios problemas de rendimiento, como la falta de equidad, el bloqueo de la cabeza de línea y la propagación de la congestión, etc., impiden su implementación a gran escala en los sistemas de producción. A través de observaciones experimentales detalladas, inspeccionamos las interacciones entre el control de flujo y el control de la congestión, y somos conscientes de que la causa radical de los problemas de rendimiento son los elementos ineficaces en la arquitectura de gestión de la congestión para Ethernet sin pérdidas, incluido el mecanismo de detección de congestión inadecuado y la velocidad inadecuada. ley de ajuste.

Inspirándonos en estos conocimientos y hallazgos obtenidos en las investigaciones de experimentos, revisamos la arquitectura de gestión de la congestión y proponemos el esquema de Notificación de Congestión Fotónica (PCN), que consta de dos componentes básicos: (i) un mecanismo novedoso de detección e identificación de congestión para reconocer qué flujos son realmente responsables de la congestión (ii) un método de ajuste de velocidad impulsado por el receptor para aliviar la congestión en tan solo 1 RTT. Implementamos PCN usando DPDK NIC y realizamos evaluaciones usando experimentos y simulaciones de banco de pruebas. Los resultados muestran que PCN mejora en gran medida el rendimiento en cargas de trabajo de ráfagas simultáneas, mitiga significativamente los mensajes PFC PAUSE y reduce el tiempo de finalización del flujo en cargas de trabajo realistas.


Terminología #

Antes de hablar sobre las mejores prácticas para crear su lago de datos, es importante familiarizarse con la terminología que usaremos en este documento en el contexto de la creación de su lago de datos con ADLS Gen2. Este documento asume que tiene una cuenta en Azure.

Recurso: Un elemento administrable que está disponible a través de Azure. Las máquinas virtuales, las cuentas de almacenamiento y las redes virtuales son ejemplos de recursos.

Suscripción: Una suscripción de Azure es una entidad lógica que se usa para separar la lógica de administración y financiera (facturación) de sus recursos de Azure. Una suscripción está asociada con límites y cuotas en los recursos de Azure; puede leer sobre ellos aquí.

Grupo de recursos: Un contenedor lógico para contener los recursos necesarios para una solución de Azure se puede administrar juntos como un grupo. Puede leer más sobre los grupos de recursos aquí.

Cuenta de almacenamiento: Un recurso de Azure que contiene todos los objetos de datos de Azure Storage: blobs, archivos, colas, tablas y discos. Puede leer más sobre las cuentas de almacenamiento aquí. A los efectos de este documento, nos centraremos en la cuenta de almacenamiento de ADLS Gen2, que es esencialmente una cuenta de Azure Blob Storage con el espacio de nombres jerárquico habilitado. Puede leer más al respecto aquí.

contenedor (también denominado contenedor para cuentas no habilitadas para SNP): Un contenedor organiza un conjunto de objetos (o archivos). Una cuenta de almacenamiento no tiene límites en el número de contenedores y el contenedor puede almacenar un número ilimitado de carpetas y archivos. Hay propiedades que se pueden aplicar a nivel de contenedor, como RBAC y claves SAS.

Carpeta / Directorio: Una carpeta (también denominada directorio) organiza un conjunto de objetos (otras carpetas o archivos). No hay límites sobre la cantidad de carpetas o archivos que se pueden crear en una carpeta. Una carpeta también tiene listas de control de acceso (ACL) asociadas, hay dos tipos de ACL asociadas con una carpeta: las ACL de acceso y las ACL predeterminadas; puede leer más sobre ellas aquí.

Objeto / archivo: Un archivo es una entidad que contiene datos que se pueden leer / escribir. Un archivo tiene una lista de control de acceso asociada. Un archivo solo tiene acceso a las ACL y no a las ACL predeterminadas.


Las cuatro categorías de DDoS

Si bien el panorama de amenazas DDoS está en constante evolución, F5 ha descubierto que los ataques continúan perteneciendo a cuatro tipos de ataques con las siguientes características:

  • Volumétrico: ataques basados ​​en Flood que pueden ocurrir en la capa 3, 4 o 7. Los ataques en L3–4 suelen ser tráfico falsificado de UDP.
  • Asimétrico: tráfico UDP unilateral o sin estado.
  • Computacional: ataques diseñados para consumir CPU y memoria, generalmente en L7 a través de TCP.
  • Basado en vulnerabilidades: ataques que aprovechan las vulnerabilidades del software.

Los mecanismos defensivos han evolucionado para lidiar con estas diferentes categorías, y las organizaciones de alto perfil han aprendido a implementarlos en arreglos específicos para maximizar su postura de seguridad. Al trabajar con estas empresas y afinar sus componentes, F5 ha desarrollado una arquitectura de mitigación de DDoS recomendada que puede adaptarse a la escala del centro de datos y los requisitos de la industria específicos.


¿Quién teme a más spam y estafas?

Los investigadores de seguridad que dependen de los datos incluidos en los registros de nombres de dominio del sitio web para combatir a los spammers y estafadores probablemente perderán el acceso a esa información durante al menos seis meses a partir de finales de mayo de 2018, en virtud de una nueva propuesta que busca alinear el sistema. con las nuevas leyes de privacidad europeas. El resultado, advierten algunos expertos, probablemente signifique que más spam y estafas lleguen a su bandeja de entrada.

El 25 de mayo entra en vigor el Reglamento General de Protección de Datos (RGPD). La ley, promulgada por el Parlamento Europeo, requiere que las empresas obtengan un consentimiento afirmativo para cualquier información personal que recopilen sobre personas dentro de la Unión Europea. Las organizaciones que violen el GDPR podrían enfrentar multas de hasta el cuatro por ciento de los ingresos anuales globales.

En respuesta, la Corporación de Internet para la Asignación de Nombres y Números (ICANN), la entidad sin fines de lucro que administra el sistema global de nombres de dominio, ha propuesto eliminar los bits clave de datos personales de WHOIS, el sistema para consultar bases de datos que almacenan los usuarios registrados de nombres de dominio. y bloques de rangos de direcciones de Internet (direcciones IP).

Según las reglas actuales de ICANN, los registradores de nombres de dominio deben recopilar y mostrar una variedad de puntos de datos cuando alguien realiza una búsqueda de WHOIS en un dominio determinado, como el nombre, la dirección, la dirección de correo electrónico y el número de teléfono del registrante. La mayoría de los registradores ofrecen un servicio de protección de la privacidad que protege esta información de las búsquedas públicas de WHOIS. Algunos registradores cobran una tarifa nominal por este servicio, mientras que otros lo ofrecen de forma gratuita.

Pero en un intento por ayudar a los registradores a cumplir con el GDPR, ICANN está avanzando en un plan para eliminar elementos de datos críticos de todos los registros públicos de WHOIS. Con el nuevo sistema, los registradores recopilarían los mismos puntos de datos sobre sus clientes, pero limitarían la cantidad de información disponible a través de búsquedas públicas de WHOIS.

Los datos a redactar incluyen el nombre de la persona que registró el dominio, así como su número de teléfono, dirección física y dirección de correo electrónico. Las nuevas reglas se aplicarían a todos los registradores de nombres de dominio a nivel mundial.

ICANN ha propuesto la creación de un & # 8220sistema de acreditación & # 8221 que examinaría el acceso a los datos personales en los registros de WHOIS para varios grupos, incluidos periodistas, investigadores de seguridad y funcionarios encargados de hacer cumplir la ley, así como titulares de derechos de propiedad intelectual que utilizan habitualmente los registros de WHOIS para combatir piratería y abuso de marcas.

Pero en una reunión de ICANN en San Juan, Puerto Rico el jueves, los representantes de ICANN admitieron que una propuesta sobre cómo podría funcionar un sistema de investigación de antecedentes de este tipo probablemente no estaría lista hasta diciembre de 2018. Suponiendo que ICANN cumpla con ese plazo, podrían pasar muchos meses después de eso. antes de que los cientos de registradores de dominios de todo el mundo tomen medidas para adoptar las nuevas medidas.

Gregory Mounier, jefe de alcance en EUROPOL & # 8216s European Cybercrime Center y miembro de ICANN & # 8217s Grupo de trabajo de seguridad pública, dijo que el nuevo plan de WHOIS podría dejar a los investigadores de seguridad en la estacada & # 8212 al menos a corto plazo.

& # 8220Si no & # 8217t tienes un sistema de acreditación para el 25 de mayo, entonces & # 8217s no hay forma de que la gente de ciberseguridad tenga acceso a esta información & # 8221 Mounier le dijo a KrebsOnSecurity. & # 8220Deje & # 8217s decir que & # 8217 está monitoreando una botnet y tiene 10.000 dominios conectados a ella y desea encontrar información sobre ellos en los registros de WHOIS, no podrá & # 8217 hacerlo más. Probablemente no se implementará antes de diciembre de 2018 o enero de 2019, y eso puede significar brechas de seguridad durante muchos meses. & # 8221

Rod Rasmussen, presidente del Comité Asesor de Seguridad y Estabilidad de ICANN & # 8217s, dijo que ICANN no tiene un historial de hacer las cosas antes o en los plazos establecidos, lo que significa que pueden pasar más de seis meses antes de que los investigadores y otros puedan ser examinados para acceder a información personal en Datos de WHOIS.

Cuando se le preguntó cuál era su opinión sobre las posibilidades de que la ICANN y la comunidad de registradores todavía estuvieran diseñando el sistema de investigación en esta época del próximo año, Rasmussen dijo & # 8220100 por ciento & # 8221.

& # 8220Muchas personas que están usando estos datos no podrán & # 8217 tener acceso a ellos, y & # 8217s no serán bonitos & # 8221, dijo Rasmussen. & # 8220 Una vez que las cosas empiecen a oscurecerse, tendrá un efecto en cascada. La capacidad de entrega del correo electrónico será un problema, y ​​la cantidad de spam que aparece en las bandejas de entrada de las personas y # 8217 aumentará rápidamente porque muchas tecnologías antispam dependen de WHOIS para sus algoritmos. & # 8221

Como señalé en la historia del mes pasado & # 8217 sobre este tema, WHOIS es probablemente la herramienta más útil que tenemos en este momento para rastrear ciberdelincuentes y / o interrumpir sus operaciones. En un día cualquiera, probablemente realice entre 20 y 30 consultas de WHOIS diferentes en los días que he reservado para una investigación profunda, puedo ejecutar cientos de búsquedas de WHOIS.

Los registros de WHOIS son una forma clave en la que los investigadores se comunican con los propietarios de sitios web cuando sus sitios son pirateados para alojar páginas de phishing o para enviar malware a los visitantes. Estos registros también son indispensables para rastrear a las víctimas, las fuentes y los propios delincuentes cibernéticos. Sigo muy preocupado por el impacto potencial de que los registros de WHOIS se oscurezcan en todos los ámbitos.

Hay un último & # 8220out & # 8221 posible que podría ayudar a los registradores a eludir temporalmente las nuevas regulaciones de privacidad: los miembros de la junta de la ICANN les dijeron a los asistentes a la reunión del jueves & # 8217 en Puerto Rico que habían pedido a los reguladores europeos una & # 8220 tolerancia & # 8221 & # 8212 básicamente, permiso para ser eximido temporalmente de la nueva normativa de privacidad durante el tiempo que lleva la elaboración e implementación de un sistema de acreditación de WHOIS.

Pero hasta ahora no ha habido respuesta, y varios asistentes a la reunión de ICANN & # 8217s el jueves observaron que los reguladores europeos rara vez otorgan tales solicitudes.

Algunos registradores ya están avanzando con sus propios planes sobre la privacidad de WHOIS. Ve papi, uno de los registradores de dominios más grandes del mundo, recientemente comenzó a eliminar la mayoría de los datos de los registrantes de los registros de WHOIS para los dominios que se consultan a través de herramientas de terceros. Y los expertos dicen que parece probable que otros registradores sigan el ejemplo de GoDaddy antes de la fecha de implementación del RGPD del 25 de mayo, si es que todavía no lo han hecho.


Ver el vídeo: Install configure and federate ArcGIS Server