There are many parts to this question.
You SHOULD start from a properly split database in which the front-end has either no tables at all or only tables used for a temporary staging area. Some folks create and populate, and then later delete a third database for these temporaries, but that is a matter of style - and also a matter of how much time you have to get that done.
All truly shared data must be in the common back-end and that either should contain no code at all or it should have a minimum amount of defensive code to launch a form if you open it. In that BE form you would try to identify the person opening the BE and cause the application to quit if that person is not authorized to work in the BE.
Your FE should be secured by having an opening form that acts like a dispatcher or switchboard form (which you can look up in this forum using its Search functions). No user (even the boss) should work from a database that exposes the navigation pane and ribbon. The switchboard has to control everything.
Ideally, you can identify the person entering the database and have a table that associates the user with a role or level of permissions or something that says "this user can to THIS but cannot do THAT." Then, each action-related form (in its Form_Open routine) can look up whatever user role, privilege, or permission you have defined in the user-related tables to decide whether it wants to allow the user to proceed. Since the Form_Open event can be canceled, you can stop the user at that point, or allow the rest of the normal form opening events to proceed normally.
Now, the question of "synchronization." There are two types of changes you can make to the database (with respect to this question). (A) The kind of changes that only affect the FE and (B) the kind of changes that require a BE change, such as adding a new field to a table or adding a new table. In EITHER case, you need to make a separate copy of both FE and BE as your "design master" and this copy NEVER gets published. It is the developer's copy. You COPY the FE to a work area and set up its security before publishing it.
For case A, all you do is publish a new copy of the updated FE and arrange for everyone to pick it up. In this forum, search for "updating front-end" to see the many strategies involved. To keep your sanity, have a local facility in the FE, perhaps in the opening form that becomes or launches your switchboard, to look at some small table in the BE so that you can, if needed, pop up a message saying "incompatible versions." But if you use the method that updates the FE every time, that would become moot.
For case B, where you need to change BE table structure, you do everything in the design master first. Then set aside some time during which you will not only update the public copy of the FE (see prior paragraph) but you ALSO update the BE. To make THAT work, you have to take good notes for every BE change including a list of the fields you add and what value you define as the initial value for the fields. Ditto, new tables. The production database must be completely unavailable at this time.
You might wish to also look up DDL (Data Definition Language) which Access CAN use and it is related to SQL. It would be a way for you to implement the structural changes quickly so that you could, for example, make a macro to implement the changes. I rarely use macros but this situation is one of the times when I will do so.
As Dave suggests, the FIRST thing to examine is the location and function of every table. Since you "inherited" this beastie, it might not be as familiar to you as you will need it to be once you become its keeper. You MUST strive for the moment that you can look at a problem relating to that database and immediately know what tables are involved. There is also no substitute for knowing the business flow intimately.
Having gone through this myself about 15 years ago, I can tell you that the Database Documenter is your best friend forever. MS Word is a close second, because there is no excuse for not documenting things as to structure and purpose.
I see I've gotten a bit long-winded. You need to do a lot of thinking so I'll leave you at this point to consider your next step. And it is YOUR next step since it is your database. We can only offer suggestions. In the final analysis, you have to implement it.