Post reply

The Justification Database

  • January 17, 2019 at 9:05 pm

    #376833

    Comments posted to this topic are about the item The Justification Database

  • January 18, 2019 at 4:18 am

    #2019341

    Why would you need exceptions? Just give anyone who asks your credentials. :hehe:

  • January 18, 2019 at 5:36 am

    #2019346

    For our DW, it was all internal. So groups were created role roles in AD, and tickets through the help desk. This worked pretty well, as it was visible to many.

    Ticket size in Kerberos was any issue for just a couple of people, but we were able to work around this.

    External access was not allowed, and they only got reports sent out by us via SSRS, parameter driven by their sales office number.

    So ours was a rather simple implementation. And the roles were all in 1 OU.

  • January 18, 2019 at 7:24 am

    #2019366

    Ideally, the DBA doesn't grant access to people, we should only grant access to functional roles. Where I work now, most access is granted using AD domain roles (ie: [SG eComm Dev] for developers on the eCommerce portal or [SG Financial Analytics] for data analysts who work with financial data). The decision about which role(s) the employee John Smith gets assigned to is determined by his executive manager, and there is a dedicated team for managing AD and network security in general, but requests for membership in a domain role (AD administration) or requests for a role to gain access to a new database (DBA) originate in ServiceNow and are assigned to the proper department.

    Shortly after I was hired, one task I did was implementing a data mart that polls across all database servers each night and aggregates reporting data about what account has access to what databases and objects. I also developed a web based dashboard for filtering the data, and the internal auditors can researching things like: "When did John acquire access to the Payroll database?" or "List all accounts that are members of the sysadmin on any server.".

    "Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho

  • January 18, 2019 at 8:26 am

    #2019371

    Rhetoric questions about the article "US ballistic missile systems have very poor cyber-security"... Was any manager who was responsible for the IT systems and infrastructure fired for such elementary failures? I'm trying to use very polite terms. I'm very doubt. They were not aware... That simply means the were not qualified for their positions. What about their managers ... I'm positive that those locations mentioned in the article/OIG Report have real IT professionals who new security deficiencies and tried to work right things, but seems was not supported by unqualified management. System failure. Unfortunately.

  • January 18, 2019 at 11:19 am

    #2019398

    When it comes to securing ballistic missile systems, maybe keeping them off the internet grid is best. I reject the notion that we must IoT everything.

    "Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho

  • January 19, 2019 at 8:15 pm

    #2019460

    You know, I really, really like the idea of having a database that tracks who has what access to what and why it was granted.  Why don't we have such a thing where I work?  Because of several issues (and yes, they're all stupid...)

    • Something of a small turf fight over whether our cybersecurity team should keep track of the access (and requests,) or our team (who manage the servers, web and database)
    • Actually creating some sort of front-end for management to use.  Money isn't unlimited, the devs we've got in our division are all tasked on other projects.  A plain database and hitting me up to query it?  That's entirely doable, and something I'll probably bounce off the boss on Tuesday.

    As for the way we handle access, we do still grant devs access, rather than using AD groups because we host multiple groups databases on one server and (most) of the devs do work for multiple applications but rarely do two devs need the same access.
    So why don't we have the databases split out by group and application?  All my servers are VMs and it was worse then trying to pull teeth from a starving Great White shark with my bare hands to get the storage, memory, and CPU I wanted / required from the group (which ISN'T part of our budget) that controls the VM environment...

    So, yeah, stupid crap.

    (Source:  I do work for the US Gov...)

Viewing 7 posts - 1 through 6 (of 6 total)

You must be logged in to reply to this topic. Login to reply