AD integration, Syslog, auditing and general security

[amirul93]

I am working on a nimble deal but the customer has a number of concerns about the lack of AD integration and auditing/logging (Syslog) which apparently is key in their environment.

The only workaround I can suggest is that they ‘lock’ Nimble management down to a single PC and conduct auditing on this management station. Not sure it is going to fly as its not an elegant solution, but I'm hoping it will be a satisfactory workaround until these features do arrive.

My other option is to do a Nimble NDA session with the customer to discuss the roadmap so that they can see exactly what is coming and when.

Has anyone else come up against these obstacles and wondering what your suggestions were and how you managed to work round them.

We are close to netting this new nimble customer, so let me know your thoughts guys.

[dsandler71 · Accepted solution]

Amirul,

In previous engagements where this has become a concern, we have implemented a system similar to what you described. This is especially true in virtual environments as you can isolate a VM on the management network and control/audit access through that layer. Borrowing from the book of Mitch Gram:

1) Create a private management network in the virtualized environment that will only be used by and Windows OS instance and the management network of the Nimble array.

2) Create an AD integrated Windows VM with two network interfaces, 1 in the primary management network and 1 in the private management network created in step 1

3) Enable their syslog infrastructure to monitor this windows instance.

4) Create a policy in their GLBA / SOC audit controls that states that users accessing the Nimbly may only do so by first accessing the VM referenced in step 2.   This log-in will be tracked by a syslog event of an AD authentication to this OS.    Also define in the policy that users will log in their internal control systems when they accesses this OS/Nimble array and for what purpose.  The audit procedure is to run a report to compare the internal control system logs with syslog AD events to this OS and confirm 100% match.

Hope this helps! If you do go through an NDA, remind the customer that any future updates are non-disruptive and inclusive under their support agreement (no cost). So they can deploy now and take advantage when things like RBAC and syslog are released. If this is a time sensitive deal, I encourage you to engage with your local sales team to discuss the timing of these releases.

[amirul93]

Thank you for the prompt response. This was in line with my thinking but the detailed response will be very useful (thanks Mitch too).

We are arranging an NDA session with the customer also so hopefully whilst not very elegant will be a satisfactory temporary solution.

[amirul93]

I wonder if the following could also be a viable option in certain environments for ongoing admin duties?

In a virtualised VMware environment, configure the vCenter plugin to manage the Nimble array and do not share the Nimble Admin password, thus forcing ongoing administrative activities to be performed via vCenter, which in most cases is plugged into AD and thus can control access. Further VMware user account policies can control which VMware admins can perform storage related activities. I am aware that only certain activities can be performed via vCenter but standard activities like expanding volumes, creating new ones, snapshot scheduling and cloning restores which probably form 95% of main activities you would perform on a Nimble in an operational environment. Again, not the most elegant solution, but it can certainly address concerns in a security conscious environment, albeit temporarily.

[dsandler71]

Absolutely. It all depends on what level of security/audit the customer requires. If the above method would satisfy their requirements, it's definitely the easiest way to go. As we release newer versions of the plugin, they'll find that they can do everything from the plugin itself as well.