I absolutely agree with alwaysblank that Composer and an automatic deploy process is the way to go. I personally use Deployer for which I have shared my setup for here. There’s also Trellis which I am not using (because of the way the company where I work do things) but I think a lot of people here would recommend it 
But I can also see the need for a quick fix and I think there are a cpl of ways to do it (test at your own risk):
If you are able to run composer on the server, you could update versions in composer.json and then run composer update there. If you have a local setup you should first do the updates there using Composer and make sure everything works and then you can upload composer**.lock** to the server and run composer install. Maybe also add some or all of the flags --verbose --prefer-dist --no-progress --no-interaction --no-dev --optimize-autoloader --no-suggest.
If using Composer is not an option, but you still want to keep anyone from updating using the admin area, you can go ahead and manually add/replace plugins in web/app/plugins and core in web/wp.
If you also/instead want to allow updates/installs from the admin area: in config/environments/production.php (and staging.php if you are using a staging environment), set DISALLOW_FILE_MODS to true. I do believe that this also enables the file editor and other maybe-not-so-good-but-default-in-wordpress stuff in the admin area.
If you wont be using Composer, and later on decide to start using it, you need to make sure to match the list in composer.json with the installed plugins and versions.