1 2 Previous Next 18 Replies Latest reply on Jul 15, 2014 10:23 PM by carojo

    External File Access Security Issue

    carojo

      I've recently been revisiting the issue / solution posted in previous discussion and further testing has revealed a problem - (see Restricting External File Access issue)

       

      To recap (this is in FM12 server evironment):

       

      User1 has unlimited access to File 1 (not under my control - developer inexperienced and has granted Full Access privilege to all users of File 1) and restricted access to my file (File 2) ie same login details allow read only / view only for File 2 records belonging to their group.

       

      To enable ease of access from File 1 to File 2 I have applied the re-login step as suggested previously (though the issue occurs regardless of this point) - which logs them into File 2 as User1_ with a hidden password - privilege set for this user has edit access to File 2 records belonging to their group.

       

      The problem is that once they have been re-logged in to File 2 with edit access, they can then go back to File 1 and access / update any fields in File 2 using layouts based on table occurrences for File 2 - which bypasses all of the restrictions & validation in my solution!

       

      So it's really back to the drawing board for me!

       

      I now can't see a way to safely allow access to my solution from File 1 at all (other than locking down security at the field level and making all updates through scripts which would be a major headache), so any advice or insights much appreciated - this is still in FM12 but I don't think it would be any different in version 13.

       

      (It would be nice if FileMaker offered a bit more granularity in how access from other files is managed rather than all or nothing!)

       

      Thanks in advance

      Caroline

        • 1. Re: External File Access Security Issue
          taylorsharpe

          If you want to manage multiple databases, it is best to do so using a Directory Service (Open Directory or Active Directory) and have everyone assigned groups and FileMaker assigns privileges based on those groups.  No secret login passwords where people don't know how they are actually logged in and their privileges might accidentally not be what you want.  To me those are just hacks to get around properly doing security with a directory service. 

          • 2. Re: External File Access Security Issue
            Mike_Mitchell

            Caroline -

             

            I tend to agree with Taylor regarding the use of a directory service; makes it much easier. You're also overcomplicating issues with the "relogin" process. If an external directory service isn't an option (for whatever reason), you should be able to use the same login credentials in both files (script password changes if necessary).

             

            But it's still a bit of a puzzle. Validations won't work from an outside file (an annoyance not only in this sort of situation, but when using the separation model as well). But the fact that they're able to override their privileges in your file is not normal. Record-level access privs should still operate based on the table in which the privileges are set. Is it possible there's an error in the permission calculation that's allowing greater access?

             

            Mike

            • 3. Re: External File Access Security Issue
              Stephen Huston

              The primary problem sounds like it's the account settings in File 1. Can't those permissions be corrected? That could fix things all around. Those permissions in File 1 are going to be an ongoing PITA if left as is, as well as being a risk to the reliability of both the file and the data. Once that's taken care of, syncing the accounts between the files is a simple solution.

              • 4. Re: External File Access Security Issue
                wimdecorte

                Stephen Huston wrote:

                 

                The primary problem sounds like it's the account settings in File 1. Can't those permissions be corrected?

                 

                +1

                 

                Using External Authentication makes things easier but only takes are of the "authentication" part (the "who are you?").  The problem here is with the "authorization" (the "what are you allowed to do?") and that is strictly in the privilege set, no matter what type of account that priv set is attached to, internal FM or external EA.

                1 of 1 people found this helpful
                • 5. Re: External File Access Security Issue
                  carojo

                  Thanks for the feedback

                   

                  Yes I am familair with using Active Directory logins but as Stephen & Wim point out it wouldn't change the underlying issue -

                   

                  The primary problem sounds like it's the account settings in File 1. Can't those permissions be corrected?

                   

                  Unfortunately I have no control over the security in File 1, and due to some sort of issue encountered by the inexperienced developer of this db, all of the users have been granted Full Access! (this developer nonethelss has a powerful position in the organisation and is not willing to give up control of their database - and the fact they have a certain amount of hostility towards the implementation of a new database leaves no room for any trust! I'm just a contractor).

                   

                  Validations won't work from an outside file

                   

                  That's a pity - and obviously not an issue in a multi-file solution implemented under common security control - unfortunately the real world isn't always like that and this does place a severe restriction on sharing data in this case, which, security issues aside, would be quite straightforward.

                   

                  Short of the IT team taking control of both files, which seems unlikely, it looks like the users of File 1 will have to live without access to live data in File 2 and I'll have to push data out to a third read-only data source as a less than ideal solution. Any other suggestions most welcome.

                   

                  Thanks again

                  Caroline

                  • 6. Re: External File Access Security Issue
                    Mike_Mitchell

                    I agree that the problem is permissions, but I'm still not convinced there's not a problem somewhere in File 2. File 1's permissions should not be able to override the permissions in File 2. (Can't tell you the number of times I've accidentally prevented someone from being able to do something because I forgot to allow a privilege set to do something in a separated solution.)

                     

                    Another option (besides pushing data to an external file) would be to set up an ODBC connection and allow them to import your data to their solution. Or get their IT department to explain the concept of security to them.  

                     

                    Good luck.

                     

                    Mike

                    1 of 1 people found this helpful
                    • 7. Re: External File Access Security Issue
                      carojo

                      Hi Mike - thanks for the quick response - regarding your point

                      File 1's permissions should not be able to override the permissions in File 2.

                       

                      That's true for fields which are not modifiable eg a UID or for simple field validation such as restricting data entry to a value list.

                       

                      However File 2 has a lot of functionality that is beyond the scope of validation set through field defintiions.

                       

                      For example many record changes result in records being written to an audit log, and in other cases an update of record status will require other information to be completed on the record. 

                       

                      I am wondering if a way to provide live data to File 1 in a secure way could be to add a copy of File 2 for read-only access (File 3).

                       

                      This third file would have read-only accounts mirroring the full access accounts in File 1 and would have identical tables to File 2 joined to File 2 TO by the table's primary key. Any fields required for display in File 1 - of which there only a few - would be defined as calculated values based on the File 2 record. Of course new records created in File 2 would need to be created in File 3 with same UID.

                       

                      Apart from losing the abillity to log straight in to File 2 from File 1 I think this would provide a safe way to access up to date information - any thoughts?

                       

                      Thanks

                      C

                      • 8. Re: External File Access Security Issue
                        Mike_Mitchell

                        I think you’re making this too complicated.

                         

                        The ability to write to an audit log is a separate issue from users in File 1 being able to edit / modify records in other tables that they shouldn’t (which was your originally presented problem).

                         

                        And you can control, on a field-by-field basis, what they can modify in File 2, using the custom permissions for their specific privilege set. So needing to complete specific fields on a record shouldn’t be an issue either.

                         

                        Any permissions that are value-list based would have to be based on a value list that lives in File 2, but that should be achievable.

                         

                        Everything you’re describing should be manageable with standard FileMaker security. I’m missing something here.

                        • 9. Re: External File Access Security Issue
                          wimdecorte

                          Mike is right, something else is off.

                           

                          if users in file 1 have full access in that file but the same account (same name) has limited access (say, read only) in file 2 -> when they are in file 1 working on a data from file 2, they will not be able to change that data.  That's how FM's privileges work.

                          • 10. Re: External File Access Security Issue
                            carojo

                            If I am missing something then I'm keen to get to the bottom of it and appreciate your input - and patience!

                             

                            As with any fairly complesx solution there are always going to be a number of ways to implement - and many elements to consider such as simplicity (for ease of maintenance) and efficiency with respect to performance.

                             

                            In the case of File 2 (my solution) the Privilege Sets do already determine which records and fields can be viewed and modified based on the group that the user and the record belongs to.

                             

                            The suggestion seems to be that all of the "business rules" for this solution should be implemented by way of conditions set through privilege sets? I appreciate that FileMaker offers a great degree of granularity in defining the actions allowed for a Privilege Set down to the field level, but to replicate all of the logic applied through scripts and triggers would entail a great deal of added complexity (also at the cost of performance?).

                             

                            Furthermore an action made on a record can have a cascade of other actions applied to other records as a consequence - I can't see how setting permissions would enable this to happen?

                             

                            I've trialed the solution using an interim File 3 to which File 1 has read-only access and this seems to solve my initial problem.

                             

                            Thanks again

                            • 11. Re: External File Access Security Issue
                              taylorsharpe

                              I suggest you review the FileMaker Security guide at http://help.filemaker.com/app/answers/detail/a_id/13291/~/the-filemaker-security-guide

                               

                              Implementing security through scripts and layouts is usually fraught with vulnerabilities and a good developer like myself can probably userp them.  Security is more properly created at the schema level and not the user interface level.  While it is ok to have security implemented with scripts and layouts, that is recommended to be secondary to underlying schema security with privileges. 

                               

                              I know you have concerns about performance.  I have folllowed FileMaker's security guideslines and use of privileges and never found a measureable performance hit from security.  Performance problems are more often in schema, unstored calculations, and poorly designed scripts.  The FileMaker security tools found in the privileges are really one of the most elegant and understated features of FileMaker. 

                              • 12. Re: External File Access Security Issue
                                wimdecorte

                                carojo wrote:

                                 

                                 

                                 

                                The suggestion seems to be that all of the "business rules" for this solution should be implemented by way of conditions set through privilege sets?

                                 

                                Not quite sure what you understand as "business rules".  But the most basic Create - Edit - Delete - View settings should be in the privilege set.  And you can use extended privileges (custom ones that you make) assigned to the proper priv set for other "toggles".

                                 

                                Like others in this thread, I fear that something really simple is being overlooked and by using a 3rd intermediate file to push copies of data around you add more complexity than needed with two potential consequences:

                                - data out of sync

                                - some security loophole left unplugged

                                • 13. Re: External File Access Security Issue
                                  Mike_Mitchell

                                  You're running into an issue that Oracle developers where I work at my day job often complain about: Allowing direct access to data in the tables bypasses business rules. Therefore, they don't allow direct access to data other than read-only.

                                   

                                  However, the problem you initially presented was that users with lower-than-proper privileges could modify data on records they shouldn't have access to. Those are two separate issues.

                                   

                                  If it's the latter, then pushing data to a third file solves nothing. You can provide read-only access in your existing database using standard FileMaker security and not have anything to worry about.

                                   

                                  On the other hand, if it's the former, and you need a "cascade of other actions" to fire off when a record is modified, then the only way for that to happen is to have access to File 1 and modify it so that it's treated as a true interface file. You can then cause scripts to fire off at appropriate times in that file, which then call scripts in your file that run with full privileges to accomplish the necessary tasks - without providing higher than necessary privileges to users. That way, you can still control what goes on in your file without sacrificing proper security.

                                   

                                  In either case, you'll still need to go back and fix the permissions in your file so external sources can't monkey with things they shouldn't be able to.

                                  • 14. Re: External File Access Security Issue
                                    Stephen Huston

                                    Caroline wrote, in part:

                                     

                                    Unfortunately I have no control over the security in File 1, and due to some sort of issue encountered by the inexperienced developer of this db, all of the users have been granted Full Access! (this developer nonethelss has a powerful position in the organisation and is not willing to give up control of their database - and the fact they have a certain amount of hostility towards the implementation of a new database leaves no room for any trust! I'm just a contractor).

                                     

                                    Is there nobody who outranks the original developer AND has any concern for the company's data security? If everyone has full access, then anyone can:

                                    • delete all data
                                    • mess with the file structure
                                    • delete tables and fields
                                    • change the functionality of or delete layouts
                                    • etc. Nothing is safe or protected from anyone who enters the file.

                                    This is really basic stuff, and should be of concern to anyone who thinks the database is worth anything to the business.

                                     

                                    Due Diligence: a hired specialist has a responsibility to make it known to whoever hired them when finding a major risk which should be addressed, even if that specialist doesn't have the authority to fix it on their own.

                                     

                                    Put it in writing, along with detailed explanations of the risk both to their existing system as well as the risk and limitations it places on what they hired you do build, and then it's on them.

                                    1 2 Previous Next