3 Replies Latest reply on May 18, 2018 6:49 AM by Marwim

    Is PL SQL Developer compliant with 3 Tier Architecture?

    Sats19

      This may be a no brainer for the experts in the forum.

       

      Information Security team in my organization is questioning whether users (developers/app support folks) should be allowed to use tools like PL SQL developer which are not compliant with a "3 tier architecture". Per them, any user directly connecting to a database from their workstations should not be allowed. I am curious if anyone has been asked this question before and how you have framed your response?

        • 1. Re: Is PL SQL Developer compliant with 3 Tier Architecture?

          This forum is for SQL Developer - PL Sql Developer is a totally different product.

           

          Can we assume you are still interested as it relates to Sql Dev?

          Information Security team in my organization is questioning whether users (developers/app support folks) should be allowed to use tools like PL SQL developer which are not compliant with a "3 tier architecture".

          What is it exactly that they are 'questioning'?

           

          I've been in the industry over 30+ years and I have NEVER heard of a developer tool that is 'compliant with a 3 tier architecture'.

          Per them, any user directly connecting to a database from their workstations should not be allowed.

          Never heard of such a thing.

           

          I don't know how any developer or DBA could get any work done at all without such direct connections.

           

          I am curious if anyone has been asked this question before and how you have framed your response?

          I strongly suspect you are leaving out, or missing, the context of their concerns or questions.

           

          It is certainly common for normal users to be restricted from direct connections and only work through a client app of some sort. But in my experience that not only doesn't apply to developers/dbas but it wouldn't even make sense for it to.

           

          The 'answer' could even be different depending on what environment you are talking about: production, QA, test, development.

           

          Typically developers don't have ANY access to production - direct or otherwise.

           

          Access/security to the DB is primarily done at the DB level through the proper creation or roles, users and granting of privileges to those roles and users.

           

          Three tier apps then get involved in access to an 'application' (not the DB itself) and can use additional user/role/privilege tables that are part of that application.

           

          In that context the application is the only 'connection' to the DB. The users access various functional components of the application via their application (not DB) user accounts. Those functional components are restricted by the application code itself as to what DB functionality they can work with.

           

          Need to create a table? That is typically done by a developer/dba using a direct connection and a tool like you mention (sql*plus, sql dev, toad, etc).

           

          Need to change the menu item order of your application? That can often be done with client app functionality whose code then makes the necessary (and hidden) changes to the actual DB objects or data.

           

          You need to provide a much more specific example of what you are talking about. The question/issue as you presented it doesn't really reflect the reality of the majority of systems out there.

          • 3. Re: Is PL SQL Developer compliant with 3 Tier Architecture?
            Marwim

            Beside the answer from rp0428 that developers need direct access:

            we rely on our users having access to the database via SQL Developer. But they have no direct access to any table or procedure, only via read only schemes. This might not qualify for 3-tire but the read only access acts as security layer. They can only see what they are allowed to see and they can only change what they are allowed to change - if you log these activities you even know who did what.

            We heavily use SQL Developer reports to provide users with informations. They are deployed at a central filer and imported as shared reports - this is much faster than implementing them in our applications. Since we do so the amount of tickets for analysis requests dropped dramatically since the users can get the data for themselves.

            What would be the difference between access through SQL Developer (or any other DB-tool) and an 3-tire application that allows users to run queries? If they need the information they need access by whatever means.