Authentication - Access Control Default Security Active Directory Trusted Authentication Guest User or Anonymous (un-authenticated) Logging Out

Transcription

1 FME Server Security

2 Table of Cotets FME Server Autheticatio - Access Cotrol Default Security Active Directory Trusted Autheticatio Guest User or Aoymous (u-autheticated) Loggig Out Authorizatio - Roles ad Policies Permissios with respect to workspaces ad data Network - Trasmissio Security Cliet to FME Server HTTP Cliets Web Applicatio Server Other Commuicatio Betwee FME Server ad the Database Other Risk Assessmets Summary

3 Safe Software s etire busiess is built o data, ad we uderstad that it is amog the most importat assets of ay orgaizatio. The security ad privacy of your data is our highest priority. FME Server FME Server brigs FME to the eterprise, ad a icreased focus o security. Ehaced security ca ofte mea a compromise o ease of use ad deploymet, but with FME Server, advaced security features are balaced with a product that is simple to use ad istall. There are 4 mai compoets to FME Server security: 1. Autheticatio Access Cotrol 2. Authorizatio Roles ad Policies 3. Data Data Security 4. Network Trasmissio Security FME Server is already trusted ad used by may orgaizatios i the oil ad gas, local ad federal govermet, utilities, higher educatio, ad military sectors. This documet describes how FME Server provides comprehesive security. Autheticatio - Access Cotrol To prevet uauthorized access, the first level of security is to establish the user s idetity. This process is referred to as autheticatio. FME Server supports 3 types of autheticatio: Default Security, Active Directory, ad Trusted, as well as a optio to allow u-autheticated access to the system. Default Security FME Server ships with a itegrated security compoet providig user maagemet ad autheticatio services. This default is geerally applied whe you are ot plaig to use Active Directory or whe you are deployig outside your orgaizatio s firewall (e.g. o FME Cloud). Whe Default Security is eabled, the FME Server is resposible for maagig the etire autheticatio process. A admi ca create ad maage users from the web user iterface. Oce users are created, they ca log i by maually eterig their credetials. Users ca also be created ad destroyed programmatically usig the FME Server REST API. This meas that creatig ad maagig FME Server logis ca be automated ad tied ito your provisioig process. Active Directory Whe Active Directory is eabled for autheticatio, all userames ad passwords are maaged by Active Directory. FME Server passes credetials to the Active Directory server, but it does ot participate i the autheticatio process. The itegratio works by effectively mappig Active Directory security groups to FME Server user accouts or roles. FME Server does ot store passwords whe cofigured for Active Directory autheticatio. 1

4 Itegrated Widows Autheticatio (IWA), commoly referred to as sigle sig-o, is also available with Active Directory. This removes the eed for users to log i to the FME Server; their Widows logi credetials are seamlessly passed alog to FME Server ad ultimately Active Directory. IWA is supported i the FME Server Web User Iterface ad i the publish wizard i FME Workbech. FME Server Itegrated Widows Autheticatio Browser Browser idicates support for diffferet autheticatio mechaisms (NTLM, Kerberos, GSSAPI) Tomcat asks for Kerberos Kerberos payload is set (icludes SPN, credetials, timestamp) Tomcat seds sucess or fail respose Tomcat LDAP protocol used to commuicate with Active Directory. Choose for cross-platform capabilities vs SSPI, which is Widows oly. Tomcat uses LDAP SASL to sed Kerberos payload for evaluatio Active Directory uses LDAP SASL to sed success or failure respose Active Directory Oce the autheticatio has bee cofigured, system admiistrators (as with default security) have the ability to fie-tue the authorizatio ad access to the differet compoets of FME Server (i.e. set up roles, grat policies, ad assig users to the roles). Trusted Autheticatio If you are developig a custom applicatio, FME Server toke security provides a robust ad simple way for trusted applicatios to iteract with all or parts of FME Server. For example, you may have a iteral self-service applicatio that allows users i your compay to dowload data out of your corporate database i a specific format. Rather tha make the user log i, you ca set up a trusted relatioship betwee the applicatio ad FME Server. Whe FME Server receives a request from a trusted applicatio, it takes the toke, performs the autheticatio process ad carries out the request. Toke security works by providig a ecrypted strig that is passed with the request, bypassig the iteractive eed to log i to FME Server. Tokes ca oly be geerated by a autheticated user with the correct policies. They are primarily used i combiatio with the REST API but all services (e.g. Data Dowload ad Data Streamig) support toke security. FME Server roles ca be used to adjust the policies to which the toke has access. Tokes are oe way SHA-1 ecrypted hashes ad ca be set to expire. Tokes are based o three uique variables which esures they are upredictable. If HTTPS is eabled, all sessio iformatio is stored i secure cookies. Guest User or Aoymous (u-autheticated) FME Server ca be cofigured to allow aoymous access to the services that ship with FME Server. This is useful for providig access to ukow users such as the geeral public. For example, a FME Server workspace could be set up to allow members of the public to upload data ito a cetralized repository via a QA process. By default, the guest accout is eabled o FME Server, however it oly grats a limited umber of policies. Loggig Out There is o sessio timeout whe logged i to FME Server. Users cocered about leavig their browsers exposed should log out of FME Server whe ot i use, or lock their computers maually or through a pre-cofigured timeout. 2

5 Authorizatio - Roles ad Policies I FME Server, a role is a group of oe or more users. Policies defie the activities that are grated for a specific role o each FME Server resource. A umber of default roles ship with FME Server: fmeadmi, fmeauthor, fmeguest, fmesuperuser, ad fmeuser. These roles are created aroud job fuctios ad are based o how orgaizatios traditioally use FME Server. However, you have complete cotrol over roles; you ca delete ay of these ad create your ow. These authorizatio capabilities allow a admi to implemet fie-graied cotrol over what cotet users ca access as well as what actios (read, write, publish ad remove) they ca perform o the cotet. For example, a user assiged to the fmeauthor default istalled role ca publish workspaces to FME Server. They ca also access the web user iterface to iteract with ay of the workflows they have published. But they caot access ay admi tasks such as Security or Egie Maagemet. Oce a user has correctly autheticated with FME Server, they are grated access to the system. Whe a user the accesses a specific compoet, FME Server security determies if ay of the associated roles of the user have the correct policies assiged to perform the requested operatio o the resource. Permissios with respect to workspaces ad data I FME workflows, workspaces ad data cotai your itellectual property. FME Server comes with built-i security focusig specifically o these compoets. Workspaces are maaged via repositories o the FME Server, which is like a folder system o the server. It is at the repository level that permissios are assiged. Ay user accout with a role that has the maage repository permissio has cotrol over which repositories users ca access, as well as the actios (read, write, publish ad remove) that ca be performed o the objects withi the repositories. For example, you could set permissios o a repository so users could see ad ru the workspaces but ot dowload them. If a user creates a repository they are automatically grated full permissios o that repository. Data ca be uploaded with the workspace, i which case the same repository level permissios apply as above. It ca be uploaded through the data upload service (via the web user iterface or a API call) or uploaded ito the resources folders which allows you to share data betwee workspaces. There are four default root resource folders: Backup, Data, Logs ad Temp. Resource folders ca also be created by a admi. As with repositories, roles ca the be assiged to the folders to esure oly users with permissio ca access the data. If a workspace cotais a published parameter with a ame cotaiig password, it will be automatically ecrypted (usig RSA asymmetric ecryptio) before it is added to the database. This esures passwords are ecrypted i the database web user iterface job history, job, egie, ad server logs. Network - Trasmissio Security FME Server is deployed both o the iteret ad itraet. For iteral deploymets, securely trasmittig data might ot be of the highest priority because security is usually provided by prevetig access to the etwork as a whole. However, it is importat to securely trasmit credetials across the etwork eve with iteral deploymets, as more access is give to the outside world to access cloud services ad sed 3

6 otificatios. For exteral deploymets (icludig o FME Cloud), trasmissio security is critical to protect data ad prevet malicious use of FME Server. There are 3 mai etwork iterfaces to FME Server: Cliet to FME Server, FME Server to Database, ad commuicatio betwee the FME Server compoets. Each of these iterfaces is described i more detail below. Cliet to FME Server HTTP Cliets The mai cliet of FME Server is the web browser which iterfaces with FME Server via the web user iterface. Cliets ca also iteract with FME Server via the REST API. This may or may ot be a web browser, but the security implicatios discussed below are the same. By default, FME Server uses stadard HTTP requests ad resposes which are suitable for most itraet deploymets. For iteret or sesitive deploymets, HTTPS ca be cofigured usig customer supplied security certificates. Whe SSL is eabled o FME Server, all cotet ad commuicatios betwee cliets are ecrypted ad use the HTTPS protocol. FME Cloud uses HTTPS as default as the istaces reside o the public web, ad we provide the certificate. If Itegrated Widows Autheticatio (IWA) is eabled o FME Server, the two compoets ca be cofigured to commuicate data uecrypted or ecrypted. If ecryptio is ot required, the SSL coectio ca be disabled ad LDAP (Lightweight Directory Access Protocol) used. If ecryptio is required, LDAPS (Lightweight Directory Access Protocol with SSL) ca be eabled which ecrypts commuicatio via SSL over port 636. LDAP ad LDAPS are equivalet to HTTP ad HTTPS. Web Applicatio Server FME Server s ative Web Services are served by the Apache Tomcat applicatio server ad FME Server uses their SSL library. Tomcat is patched with the latest security updates with every major release ad service pack. Oracle WebLogic ca also be cofigured to work with FME Server. Cross-origi resource sharig (CORS) is supported o FME Server. This allows web applicatios to be created that access FME Server Web Services or REST API fuctioality o a differet domai. For example, if FME Server is o ad your applicatio is o you will be able to coect usig JavaScript. This access would ormally be forbidde because of the same origi policy which permits scripts ruig o pages origiatig from the same site, but prevets access to DOM from differet sites. CORS defies a way for the browser ad the server to iteract securely, ad determie whether to allow the cross-origi request. Other The otificatio server that ships as part of FME Server allows you to coect over several differet protocols to both receive ad sed data. 4

7 To esure messages set to FME Server are ecrypted ad secure: The FME Server SMTP publisher supports SSL ad TLS secured. The FME Server IMAP Publisher supports SSL, TLS, ad StartTLS. JMS: The Java Messagig Service protocol is secured with userame ad password. JMS servers with ecryptio eabled are also fully supported. WebSocket Server: The built i WebSocket Server ca support either usecure or secure coectios. WebSockets over SSL/TLS (WSS), like HTTPS, are ecrypted ad protect agaist Ma-i-the-Middle attacks. WSS ca be cofigured usig customer supplied security certificates. FTP: The FTP protocol is supported allowig files to be placed o a FTP after traslatio. Both FTPS (SSL/TLS ecrypted) ad FTPES (explicit FTP over SSL/TLS) are supported. UDP: The UDP protocol is ope to ay cliet that kows the cofigured UDP port of the publicatio, but the trasmissio of the data is guarded by topic security. FME Server will discard data uless it s cofigured to publish to a topic. Push: The push protocol is a HTTP subscriber that allows data to be set to a HTTP edpoit. HTTPS is supported so data ca be set ecrypted. If the edpoit requires autheticatio, a userame ad password ca be supplied. Commuicatio Betwee FME Server ad the Database FME Server uses the database to store metadata related to the published workspaces ad data, security, trasformatio, cofiguratio, ad jobs. FME Server uses JDBC to coect to the database. Server ca also be cofigured with your ow database (PostgreSQL, Oracle, SQL Server). However, sice FME Server to database commuicatio is usually behid a firewall, most customers will ot ecrypt this. Specific sesitive data withi the database is ecrypted. Passwords ad tokes used to autheticate with FME Server are saved, hashed, ad salted i the database. Passwords defied i workspace published parameters are ecrypted usig RSA asymmetric ecryptio. Other Risk Assessmets Applicatio desig is a combiatio of secure desig practices ad regular audits. To esure the security of FME Server, a third-party Certified Iformatio Systems Security Professioal (CISSP) was hired to complete a applicatio ad etwork security audit. This icluded etwork vulerability scaig, peetratio testig, ad a architecture review. Summary FME Server provides a robust, secure way to trasform ad automate your data coectios at a eterprise level. Customizable security settigs eable you to cofigure FME Server to adapt exactly to your orgaizatio s eeds. If you wish to discuss ay aspect of FME Server security, please cotact us ad we will be more tha happy to help. 5