Вопрос: Как грамотно настроить автоматические обновления на боевом Ubuntu Server?

Лучший ответ: 1. По опыту скажу что на production-серверах обновление лучше делать вручную, если нету зеркального сервера для тестов. Периодичность обновления советую раз в 15-20 дней. Разумеется, в случае экстренных проблем с безопасностью типа heartbleed, как ты упомянул, обновлять надо сразу, при выпуске заплаток. 
2. Если не осиливаешь пока chef и puppet почитай про Ansible. У него порог вхождения существенно ниже чем у вышеупомянутых и поддерживать его в дальнейшем намного проще, а по функционалу, если честно, он не уступает. 
3. Общие советы. Отключи не используемые службы (rpcbind, nfscommon) к примеруЗаблокируй не используемых пользователей, проверь не имеют ли системные пользователи паролей (в /etc/shadow наличие хеша во втором поле, если имеют а доступ им не нужен ставь '!')Желательно включить ssh авторизацию только по ключам, включить опцию AllowUsers со списком пользователей которым авторизироваться разрешено. Отключить авторизацию по ssh root и создать системного пользователя с оболочкой sh, без всяких привилегий. Его занести в AllowUsers, при логине выполнять /bin/su - с полным путем. По возможности все используемые службы контролировать TCP Wrappers (/etc/hosts.{allow,deny}) Установить библиотеку snoopy (snoopy logger) - очень подробное логирование запускаемых процессов. Соответственно настроить rsyslog/syslog-ng и перенаправлять логи желательно на сторонний сервер. Для логов есть различные веб-морды с различными отчетами и сортировками. Для контроля версий конфигурационных файлов советую использовать git в /etc либо выносить под различные службы в отдельные репозитарии и, конечно, настроить правильно .gitignore. Тут же присмотрись к подсистеме событий файловой системе inotify и отличному демону incron. Он пригодиться может не только в этом пункте, с ним можно много интересных вещей контролировать. По возможности настраивай все службы и сервисы в chroot окружении. Iptables. Можно на нем, а можно к примеру на ipset настраивать правила. Тут все просто. Лучше сначала создай скрипт на тестовой машине. Политики по умолчанию - deny all, а дальше разрешаешь что нужно. Конкретно что то посоветовать не имеет смысла если ты как обезьянка начнешь копировать без понимания. Есть отличная литература по iptables. А дальше ищи в интернете iptables tips, примеры настройки iptables и вникай что там делают и для чего. Но не перемудри. Понимай что пакеты пробегают по всем цепочкам правил. Это нагрузно. Задумайся об использовании ipset. 
Всякие fail2ban-ы советовать не буду. Слишком спорно и не нужно если ты правильно отстроишь любой сервис работающий поверх netfilter. Так же многие хостинги из коробки имеют защиту от DDOS и брута на уровне своего железа типа ASA-к и тд. 
Периодически делай срезы tcpdump-ом (особенно в подозрительных ситуациях) и анализируй wireshark-ом. Постоянные бэкапы, хоть rsync, fsbackup, unison, bacula и тд - выбор большой
Вообще это далеко не все, но "настроить и забыть" на production-сервере плохая идея. 
Подключай мониторинг. 
Для этого могу посоветовать 4 системы (это лично мои приоритеты, но их оочень много). Zabbix, Nagios, Sensu, Cacti
Хорошим вариантом будет установка zabbix_agent-а не сервер и удаленный мониторинг с другого сервера. Настроишь свои скрипты + анализ логов syslog и вот уже залог достаточно устойчивой и на мой взгляд хорошо защищенной системы.

Худший ответ: С никсами .. только для себя работаю. Сервисы под ними не держу. Но тебе в любом случае поможет пару советов.
0. Своевременность
1. Тестовая машина
2. Временной фактор 
3. Единообразие
4. Квалификация
Любые телодвижения начинаются с первого пункта. Желательно копии работающей машины. После обновления машина остается работать и наблюдаешь за ее самочувствием. Если всё прошло норм ... накатывает обновления на все!!! машины. Не нужно мудрить что-то. Иначе потом заипешься. Ну и последний этап. Всегда что-то вылезет! Тут уже приходится городить костыли или работать на живую. Чтоб исправить что-то что ты не планировал. И ВСЁ ЭТО НУЖНО ДЕЛАТЬ СВОЕВРЕМЕННО!!! А не ждать до последнего. 
примечание ... иногда легче мигрировать сервером на другую виртуалку чем подбирать сопли на старой.