1 Buenos Aires, Octubre 2006 Administración Federal de Ingresos Públicos La estrategia de seguridad

2 El alcance de la organización AFIP recauda la totalidad de los impuestos federales. Esta actividad incluye la recaudación, la cobranza coactiva, los procesos de ejecución fiscal, regímenes promocionales, etc. AFIP recauda los impuestos locales de varias provincias AFIP controla en forma integral el comercio exterior (Aduana), AFIP recauda, controla y distribuye a los efectores sociales la totalidad de los recursos económicos de la seguridad social AFIP posee empleados distribuidos en más de 320 edificios, incluidas las agencias impositivas, aduanas, etc.

3 El contexto informático Todas las áreas informáticas están concentradas en una única estructura cuya máxima autoridad (CIO) depende directamente del Administrador Federal El área informática de AFIP tiene 750 personas de las cuales un 50% están directamente relacionadas con el desarrollo y quality assurance de los sistemas El centro de cómputos central alberga la totalidad de los servidores y computadores centrales de AFIP

4 El escenario informático/funcional El 95% de las transacciones del comercio exterior son electrónicas El 90% de las transacciones impositivas y de seguridad social son electrónicas, y el 85 % entran en nuestros sistemas por Internet con actualización en tiempo real de las bases de datos Desde hace cuatro años el 100% de los sistemas se desarrollan con la gran mayoría de sus transacciones efectuadas directamente por el contribuyente a través de Internet

5 El escenario informático/funcional La mayoría de las bases de datos son accedidas en tiempo real y en forma simultánea por los contribuyentes, los operadores aduaneros y los empleados de AFIP pudiendo ser modificadas por todos ellos Salvo en el caso del sistema aduanero María, el 100% de los accesos internos y externos a las bases de datos se efectúa utilizando transacciones Web

6 El escenario informático/funcional El 70% de los programas interactivos y web services están implementados en Java, PHP u Oracle PL sobre Linux, 15% en PHP o ASP sobre Windows 85% de los programas interactivos son WEB enable nativos, el 15% restante son cliente servidor o emulación terminal 100% de los desarrollos que se efectúan desde hace cuatro años son WEB enable nativos, 70% de ellos en Java

7 El escenario informático/funcional Todos los datos de la organización están protegidos por el secreto fiscal, el secreto estadístico y/o el Habeas-Data La gran mayoría de las transacciones usadas por los ciudadanos requieren autenticación En la mayoría de los casos, estas transacciones son efectuadas en nombre de personas jurídicas (empresas)

8 El escenario informático/funcional Todos los sistemas (impositivos, administrativos, aduaneros, seguridad social, administrativos, etc.) están totalmente integrados entre sí La integración se implementa a través del acceso en forma directa de un sistema a las bases de datos de los otros sistemas y en el uso de un message broker AFIP posee tiene en producción mas de 200 sistemas de los cuales unos 30 son core.

9 La estrategia

10 Desde el punto de vista de seguridad, el objetivo de llevar todas las transacciones de la organización a Internet y poner a disposición de los ciudadanos las bases de datos requirió: Diseñar una arquitectura de sistemas que redujera los intentos de penetración Fuertes medidas de seguridad física Fuertes medidas de control de acceso a las aplicaciones y web services Fuertes medidas de detección y neutralización de ataques Todo lo anterior debía ser definido antes de comenzar a exponer las bases de datos y aplicaciones al exterior

11 Respecto a la estructura organizativa de seguridad informática

12 Se definió e implementó una estructura en la cual el área de Seguridad Informática depende directamente del CIO en un pié de igualdad con las áreas de desarrollo y el área de operaciones El área de Seguridad Informática tiene una “división de control de accesos” cuya misión es administrar la seguridad física del centro de cómputos y la seguridad de accesos a las aplicaciones, sistemas operativos y bases de datos Tiene también otra división dedicada exclusivamente a la detección y control de intrusos. Este área maneja los firewall, los IDS, los WAF, el rankeo en tiempo real de los ataques, etc. Que se definió e implementó

13 La seguridad de acceso a los sistemas desde el interior de AFIP

14 Desafíos del problema Se debe autenticar y autorizar a más de empleados que trabajan en las oficinas de AFIP y o fuera de ellas La autenticación debe poder ser efectuada por métodos tradicionales (passwords) y/o con métodos más fuertes (hardware tokens, etc.) Todo el proceso de autorización debe estar regido por reglas de negocio definidas por las áreas definidoras/usuarias Todo el proceso de autenticación/autorización debe estar íntimamente relacionado con el sistema de recursos humanos Todos los procedimientos de autenticación, solicitud de acceso a sistemas, autorización de accesos, etc. deben ser totalmente automáticos sin participación de Seguridad Informática

15 Que se desarrolló e implementó Se desarrolló utilizando software libre un único sistema de autenticación/autorización para el acceso desde dentro de la AFIP a todas las aplicaciones. El sistema: – Está totalmente desacoplado de los sistemas – Implementa SSO utilizando passwords/hardware tokens/fingerprint/ 802.1X – El proceso de otorgar/denegar una solicitud de acceso a una determinada transacción a una determinada persona es totalmente automático y está regulado por el sistema de recursos humanos y por reglas de negocio que definen y actualizan las áreas usuarias – Permite pre y post proceso de los accesos – Implementa mecanismos de confianza entre aplicaciones

16 La seguridad de acceso a los sistemas desde Internet

17 Desafíos del problema Se debe autenticar y autorizar a más de de personas físicas que trabajan con AFIP en nombre propio o en nombre de más de personas jurídicas (empresas) El sistema debe ser capaz de autenticar un millón de personas diariamente El sistema debe soportar el concepto de niveles de seguridad ya que no todas las transacciones requieren el mismo nivel de seguridad de registración/autenticación (curriculums, despachos aduaneros, etc.) El sistema debe poder ser usado por otros organismos del Estado (autenticación federada)

18 Se definió un modelo/sistema de autenticación y autorización federada de ciudadanos y empresas basado en el modelo de e-authentication del NIST El modelo define 4 niveles de registración/autenticación y asocia las diferentes transacciones al mínimo nivel que las mismas requieren El sistema soporta la asociación entre personas físicas y empresas y las transacciones que puede ejecutar una determinada “dupla” En estos momentos el sistema está autenticando a más de de personas y es usados por varios organismos del Estado Que se desarrolló e implementó

19 La seguridad física del centro de cómputos

20 Desafíos del problema Se debía definir la hipótesis de contingencia catástrofe y consecuentemente determinar las acciones a tomar para neutralizar estas hipótesis En adición a la hipótesis de contingencia catástrofe, se debían tomar todos los recaudos necesarios para elevar al máximo posible la seguridad física del equipamiento crítico Esto implicaba definir que se entiende por “máximo posible” y que se entiende por “equipamiento crítico”

21 Se definió una hipótesis de contingencia de catástrofe que no incluye riesgos de tifones ni terremotos. Se definió e instrumentó una estrategia de “sala cofre” más un “cold site” Se llevaron las condiciones de seguridad física del data center al máximo disponible con la actual tecnología. La instalación está certificada EN 1047/2 y en el más alto nivel de madurez de la TIA 942, Se implementaron controles de acceso sofisticados que incluyen 5 niveles, los tres últimos de ellos biométricos y muy sofisticados sistemas de “surveillance”. Que se desarrolló e implementó

22 Respecto a la arquitectura y la seguridad

23 Desafíos del problema Se debía definir una arquitectura de sistemas que en si misma asegurara un mínimo de seguridad de penetración La arquitectura a definir debía ser posible de implementar en todas las plataformas de desarrollo vigentes en AFIP La arquitectura a definir no debía requerir la adquisición de software propietario

24 Se diseñó una arquitectura basada en una capa perimetral de servidores de granja que tienen el rol de “bastión” y en los cuales reside la lógica de presentación y parte de la lógica de negocio Todos los programas que corren en estos servidores son “state- less” y cuando acceden hacia adentro del data center cambian de protocolo En ningún caso se accede a los servidores centrales usando http (port 80) En todos los casos la tunelización (IPSEC, SSL) se efectúa en el firewall perimetral Esta arquitectura es idéntica hacia Internet como hacia Intranet Que se desarrolló e implementó

25 Que se desarrolló e implementó

26 Respecto a los web services

27 Desafíos del problema Se debía definir un standard de web services que permitiera el desarrollo masivo de los mismos en cualquiera de las plataformas de desarrollo usadas en AFIP Partiendo de la premisa de que todos los web services requerirán autorización (no habrá web services totalmente públicos) se requería el diseño de un modelo que otorgara seguridad a los intercambios de información Los standard existentes hace cuatro años eran totalmente inmaduros y muy volátiles El modelo debía poder ser implementado usando software disponible en la organización

28 Se diseñó un protocolo montado sobre SOAP que incluye la lógica de autenticación/autorización de los servidores clientes y/o proveedores de servicios web Esta lógica utiliza certificados digitales para autenticar el computador cliente y la generación de “tickets” firmados por el computador proveedor con la autorización necesaria para usar un determinado servicio web El protocolo incluye lo necesario para asegurar la unicidad de los mensajes (reliability parcial) El protocolo, que no requiere software propietario ya ha sido implementado en decenas de servicios web en Java, PHP, ORACLE PL, ASP y mainframe Que se desarrolló e implementó

29 Nuevos desafíos

30 El monitoreo de los sistemas implica que se deben ejecutar permanentemente completas transacciones de prueba en el entorno de producción Las cambiantes modalidades de ataques requieren mucha velocidad de adecuación a los mismos y la utilización de herramientas muy poco estables y maduras La gran cantidad de diferentes transacciones en uso y la inherente volatilidad que ellas tienen, dificulta el uso de standards que aseguren niveles de seguridad muy altos El uso de “appliances” que comparten lógica de comunicaciones y de seguridad conspira con la separación de funciones Nuevos desafíos

31 Indicadores

facturas electrónicas autorizadas pólizas de caución electrónicas recibidas claves fiscales otorgadas En el año Indicadores

DDJJ impositivas por Internet pagos por Internet (U$S millones) transacciones a “Mi Registro” liquidaciones de planes de facilidades despachos de Importación despachos de Exportación ingresos válidos con Clave Fiscal Indicadores En agosto

hits diarios a la página de AFIP (excluidos los accesos vía Akamai quién a su vez transfiere 2.5 GB por día) hits diarios a Intranet trámites diarios (mostrador virtual) Diariamente Indicadores

de claves fiscales activas páginas en el sitio ww.afip.gov.ar 99.5% de up-time de los servicios Otros Indicadores

36 Muchas gracias Administración Federal de Ingresos Públicos Argentina