sponsored links

Collapse

Announcement

Collapse
No announcement yet.

Limiting Use of SQL

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Limiting Use of SQL

    We are trying to shore up some security and need to limit the use of running SQL statements that could update databases. We know we can secure the STRSQL command but can anyone give me some pointers to not allow a user to run SQL scripts from Systems Navigator? Any other spots where a user can perform SQL that I am missing?

    Thanks in advance!!!

  • #2
    Surely the way to limit this is via User Authority. If you just close individual access points like this you will have a never ending list of things to block. So you stop Run SQL scripts in ACS - what about Run SQL scrips in the old (but still present) Ops.Nav? What about ODBC access from Microsoft access - or any other ODBC/JDBC client. A Java app on any platform using JT400? Python, PHP, etc. etc. It goes on and on - and that's just a few of the tools available today.

    Security needs to be planned - any piecemal approach is doomed to failure and only gives a temporary sense of safety.

    Comment


    • #3
      Yeah... security is not my forte. I was tasked in finding out the best way to limit SQL and SQL scripts. This looks a little bigger than my knowledge base.

      Thanks for the pointers. I will take that back to the powers that be and let them decide on how to proceed.

      Comment


      • #4
        Much as I like this forum, you'll find a lot of folks with a wealth of security knowledge on the Midrange.com midrange-L list. My own security knowledge is not probably much greater than yours except that I know where the bear traps are from years of working with folks like Carol Woodbury and Pat Botz who really know that stuff. In other words I know who to ask <grin>

        Comment


        • #5
          Also don't forget, there are 3rd party options that hook into the exit points and provide pretty good security from outside access

          Comment


          • #6
            Like Jon said, object level security is your safest bet. Unfortunately that can be problematic, depending on how much technical debt you may have.

            The QIBM_QZDA_SQL2 (ZDAQ0200) exit point allows you to interdict external DB requests and optionally reject them.

            Comment


            • #7
              Exit point security using products such as Cilasofts (Syncsort) Controler will allow you to accomplish this.

              Comment


              • #8
                Hi.

                I think the best option is using the SQL command GRANT.

                If you want to do that in a Windows screen, you can change every authority (object and data) in ACS.

                Here you are an example (sorry, I'm running the spanish version of ACS)

                The other way, directly in SQL script, is: GRANT DELETE ON TEST_DATA_AUTHORITY TO USER_NAME;



                I hope this help you.

                Comment


                • #9
                  Originally posted by Rocky View Post
                  Exit point security using products such as Cilasofts (Syncsort) Controler will allow you to accomplish this.
                  HelpSystems has a product as well.

                  Comment


                  • #10
                    Yes - I'm familiar with that product - we used it when it was Powertech (before Help Systems) and went to Cilasoft because 1.) Cilasoft, at least at that time, was a better product and 2.) Cilasoft had a lot more ethics than Powertech. Powertech had horrible business practices. As a Help Systems customer I'm confident they have straightened out that latter issue as they are a reputable company. It's been a number of years so I can't speak to the functionality anymore...

                    Comment

                    sponsored links

                    Collapse

                    Working...
                    X