ArcGIS Online: How is My Data Safe if it’s Stored in the Cloud?

May 22, 2016 — Skye Perry  [9:39]

Utility companies often ask “When leveraging Esri’s platform technology, ArcGIS Online, how do we use our back office data while keeping it secure?”

During this brief video, Skye Perry, with SSP Innovations explains how the online GIS platform gives utility companies the ability to utilize authoritative GIS data from behind the firewall alongside editable/collectable GIS data in a very secure and flexible manner.

Is your utility, telecommunications company, or pipeline operation interested in getting up and running on ArcGIS Online, ArcGIS Enterprise, and/or Portal for ArcGIS? Learn about the jumpstart option from SSP on our GIS Jumpstarts overview page here. We’ll get your team up and running quickly on the leading Esri web GIS platform.


Hi my name is Skye Perry and I am with SSP Innovations. I wanted to come and talk to you about a common architectural question about Esri ArcGIS Online, and keeping your data maintained and secure in the back office while enabling it to use all the new Esri tools.

Some of those key tools are things like the collector, Esri ArcGIS for iOS/Android, Esri ArcGIS Explorer. There's a lot of these great applications that Esri has developed for us, and our goal is to make that data available to it on any device, anywhere, at any time by using the new platform, Esri ArcGIS Online which is abbreviated here as One of the common questions we get from all of our customers is "how do we use our back-office data while keeping it secure to enable these new patterns."

Let's dig in a little bit. We will start off a common point that all our customer start with and what they typically have in place today. That's the back-office internet (data). This is your Oracle/SQL Server geodatabase where your authoritative Esri data, feature classes, Esri feature classes, and this could certainly be ArcFM™ stored here in the back office. Whatever data you have housed that you want to expose there and secure, we want to keep it that way. We will start there. Assuming you have that in place. The next component down here on the bottom left is Esri ArcGIS for Server. Now many of you may already have ArcGIS for Server and if you do that's great. But sometimes this is a new component. Key point to note that it is still in the back office, completely behind our firewall. Our first step is to get this exposed, and take this data from your Oracle/SQL Server geodatabase and get it exposed out into ArcGIS for Server. Typical there, you are likely already be doing this.

Next key component, we are exposing either maps services or feature services from your ArcGIS for Server. They come out as REST endpoints. This is really the key; the web service can be consumed by many different applications and websites. The next key component, is to secure these REST services. We'll do that with a couple different options. At first, we might consider ArcGIS for Server authorization and that basically implies that we are going to keep a local user and a password stored within the ArcGIS for Server. Many utilities use that and works just fine. We can alternatively go ahead and use the authentication via your existing authentication with Microsoft, totally optional. Either way, we would want every server coming out of this ArcGIS for Server, locked down with a username and password, one way or another. That is our first key component.

Now our next challenge is to get that data exposed, securely, out beyond our firewall. So, we move over to your DMZ (demilitarized zone). This is a location that is typically less secure than your back office. however, not fully exposed into the internet. But we are going to use this as a box essentially as a proxy to consume the back-office data while providing a buffer between the back office and the actual internet. We got some great products here that we can plug in to do just that.

First one to note is our ArcGIS web adapter. Part of ArcGIS for Server sits right on top of Microsoft IIS and will basically natively consume our data from the back office and expose it out via a web server. So, let's talk about that for a moment. We need to broker this data in and punch through the firewall into our internal ArcGIS for Server. We would want to lock this down as far as we can. The only part we are going to open is your port 6433. As a note, a typical web server terminology of 6433 is your secure HTTPS socket layer. We are using 6433 which is what ArcGIS uses for the same purpose, to punch through the firewall and get here. The point is that all of our HTTPS is fully secure, and the data is encrypted between this channel. By only opening this exact port between a fixed IP from the DMZ and a fixed IP here inside of your back office, we are limiting that traffic down to communicating these two different servers. So now we have exposed these data points. This brings out the REST endpoints out into our DMZ. That is our next stage.

Just to note here, we now have a REST endpoint available in the DMZ. Let's jump over and talk a little bit about and our devices. This is a generic representation of whatever device and whatever application might consume this data. First key point, we are going use this name user concept available through, and that's where our user story can be located. Different users may have access to different maps via groups. Perhaps a back office user can see everything. Our executives may only see executive overview maps. Our field workers can see collection based maps. That's all managed here via the store. You can alternatively manage this via active directory if desired, but there's some additional configuration and architecture required to do so.

Here we are going to assume we are using ArcGIS Online as your data store for your user authentication and authorization out here on the cloud. Let's talk about that first. As I take my device here, let's call it an iPad. I log into, and I am able to get a certain set of data. Key point is WebMaps. Everything Esri ArcGIS aligned is focused on the WebMaps which drives the content that I am able to see within my application. So, as I transfer this WebMaps over to this device, people get confused and may think that the data is stored in the cloud.

Now note, our data has not left our back office. The data is still stored in the back office. We've got to expose the REST endpoint into our DMZ via encrypted connections. So how are we going to get that data? The WebMaps includes a reference using the concepts of HTML5 and a Javascript API allowing the client to directly consume those REST endpoints. And what do I mean by that? This is an important point.

The WebMaps comes down. The iPad consumes that endpoint. Instead of going back through the cloud to get the data, for view services, our iPad comes across directly through the internet into our web adapter to consume those REST endpoints. So, we are talking about purely view services. We got read only services. We are never going through the cloud to get it. It is device directly to the web adapter. Punching through to our service.

Data is all housed in the back office. One key point to bring up about this entry point to the IIS is we would want to lock that down too. We will only make this port 433. Which of course is HTTPS. We'll have a valid service certificate here, and we are combining it with a user name and channel from the security side of our ArcGIS for Server and with encryption all the way to the device, which gives you a secured channel to expose that data out. This is a very common practice in many other utility applications, so using and extending it into our ArcGIS Online environment is usually pretty common so most folks can get behind this.

Final step I want to talk about is editing. One of the real interesting pieces is that editing is using the cloud here ( as a proxy. To be clear, no data is stored in the cloud it is actually just references the proxy through the cloud. The data is stored in the back office. This is only for editing. In that case, we actually need to allow the iPad to see and the internal web adapter published via a public IP. We also need to ensure we can see the line between and the web adapter. This is going to be a public URL, call it Referenced here from the ArcGIS for Server and it is available in both locations. So, we are using an edit proxy here, and that same proxy is also used here. We have done that in some pretty low level network, so we are pretty confident in all of these components. When exposed this way, it works flawlessly.

Key points to take home, the data is only ever stored in your back office geodatabase, keeping it secure behind your firewall. We are exposing only secured and encrypted channels out to the internet, and we got a box in the DMZ that is brokering that data from the back office to the internet. Everything here is secured via username and password. Everything here is secured by your ArcGIS online data store for authentication and authorization. The summation of all of this is that the data is accessible via collector: ArcGIS for iOS, ArcGIS Explorer, and maybe a custom application that exists on your public website (i.e. public outage map for example). To sum this up, we are keeping your data secure while enabling your back office investment that you already have today to be consumed fully by Esri's new platform, and that's going to bring home success, thanks.

We Wrote the Book

The Indispensible Guide to ArcGIS Online

Download It for Free

Skye Perry

What do you think?

Leave a comment, and share your thoughts

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes:

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

This site uses Akismet to reduce spam. Learn how your comment data is processed.