技術記事

micomia株式会社では、アプリ・Webシステムの開発を行う企業として、情報セキュリティ体制の強化を継続的に進めています。

システム開発会社では、顧客から共有される資料だけでなく、ソースコード、クラウド環境、データベース、APIキー、各種サービスの認証情報など、多くの情報資産を取り扱います。

開発するシステムそのもののセキュリティ対策に加えて、それらを扱う社内環境についても適切な管理が必要です。

micomiaでは、ISO/IEC 27001（ISMS）の取得を見据え、端末・アカウント・アクセス権限・開発環境・社内規程などを対象に、情報セキュリティ体制の見直しを進めています。

本記事では、現在実施している主な取り組みについて紹介します。

1.情報セキュリティ対策を見直した背景

事業規模が小さい段階では、利用するサービスや端末の数も限られているため、個別管理でも大きな問題が発生しないことがあります。

一方で、従業員や案件数が増えるにつれて、

• 誰がどのシステムへアクセスできるのか

• 誰がどの端末を使用しているのか

• 本番環境へアクセスできる担当者は誰か

• 退職した従業員の権限が適切に削除されているか

• APIキーや認証情報がどのように管理されているか

といった事項を組織として把握する必要が生じます。

システム開発会社では、顧客環境へのアクセス権限を持つケースもあります。

そのためmicomiaでは、個人の注意に依存したセキュリティ対策ではなく、会社として管理・確認できる仕組みを構築することを重視した運用体制を整えています。

2. 会社で利用する端末の管理

最初に見直した項目の一つが、MacやiPhoneなどの業務で使用する端末です。

会社から端末を支給していても、設定や利用状況が各従業員に任されている場合、会社として一定のセキュリティ水準を維持することが難しくなります。

micomiaでは、Apple Businessを利用してApple製デバイスの管理体制を整備しています。

端末管理では、下記の内容を管理するようにしています。

• 会社が保有する端末の把握

• 利用者との紐付け

• セキュリティ設定の統一

• 業務に必要なアプリケーションの管理

• 紛失時の対応

• 退職時の端末回収

• 管理対象Apple Accountの運用

端末管理を個人に依存させず、会社として管理できる状態を作ることが目的です。

Apple Businessを利用した具体的な端末管理については、別記事で詳しく紹介する予定です。

3. アカウントとアクセス権限の管理

現在のシステム開発では、多数のクラウドサービスを利用します。

micomiaでも開発業務に応じて、GitHub、Google Workspace、Apple、AWS、Google Cloud、Firebaseなど複数のサービスを利用しています。

サービスが増えるほど重要になるのが、アカウントとアクセス権限の管理です。

micomiaでは原則として、業務上必要な範囲に限定して権限を付与する考え方を採用しています。

例えば、アプリ開発を担当しているからといって、必ずしも組織全体の管理者権限が必要とは限りません。

各サービスについて、管理者、開発担当者、閲覧のみ必要な担当者、本番環境へアクセス可能な担当者などを整理し、業務内容に応じて権限を設定します。

必要以上に管理者権限を付与しないことで、アカウントの誤操作や不正利用が発生した場合の影響範囲を抑えることができ未然に影響が広がることを防いでいます。

4. 多要素認証と認証情報の管理

アカウント管理とあわせて、多要素認証についても見直しています。

特に、クラウドサービス、ソースコード管理サービス、管理画面など、重要な情報へアクセスできるアカウントについては、パスワードだけに依存しない認証方法を採用します。

また、APIキーや秘密鍵、アクセストークンなどについても、ソースコード内へ直接記述しないことを基本としています。

認証情報がGitリポジトリへ保存されると、リポジトリ上から削除した場合でも履歴に残る可能性があります。

そのため、Secret Managerなどを利用してソースコードと認証情報を分離して管理します。

5. GitHubを含む開発環境の管理

システム開発会社にとって、ソースコードは重要な情報資産の一つです。

micomiaでは、GitHubなどのソースコード管理環境についてもアクセス権限や運用方法を見直しています。

主な対象は、下記の項目です。

• Organizationへの参加者

• Repositoryごとのアクセス権限

• 管理者権限

• ブランチ運用

• Pull Request

• コードレビュー

• シークレット情報

• 外部連携サービス

単にリポジトリを非公開にするだけではなく、「誰がどのコードへアクセスできるのか」を管理することが重要です。

また、不要になったアカウントや外部サービスとの連携についても定期的に確認しています。

6. セキュアコーディング規約の整備

情報セキュリティ対策は、社内インフラだけではありません。

顧客へ提供するシステム自体についても、開発工程で一定のセキュリティ基準を設ける必要があります。

micomiaでは従来のコーディング規約に加えて、セキュリティに関する開発ルールの整備を進めています。

対象としているのは、代表的な下記の内容です。

• SQLインジェクション

• クロスサイトスクリプティング（XSS）

• CSRF

• 認証

• 認可

• 入力値検証

• ファイルアップロード

• APIアクセス制御

• セッション管理

• 機密情報の取り扱い

• ログ出力

• セキュリティヘッダー

エンジニア個人の経験や知識だけに依存するのではなく、会社として最低限確認すべき項目を共通化することを目的としています。

これにより小規模の開発会社に起こりがちな属人化と担当者による質のムラを防いでもいます。

7. クラウド環境の権限管理

micomiaでは、Firebase、Google Cloud、AWSなどを利用したシステム開発を行うことが多いです。

クラウド環境では、IAMなどを利用して詳細な権限設定が可能です。

利便性を優先して広い権限を付与すると、必要以上に多くの環境へアクセスできる状態になることがあります。

そのため、開発環境、ステージング環境、本番環境を区別し、本番環境については特にアクセス可能な担当者を限定することを基本としています。

また、案件終了後や担当変更時には、不要になった権限を継続して保持しないよう管理します。

8. 入社・退職時の管理

情報セキュリティでは、従業員の入退社時の対応も重要です。

入社時には業務に必要なサービスへのアクセス権限を付与しますが、退職時にはそれらを確実に停止する必要があります。

対象となるサービスが増えると、人の記憶だけで管理することは難しくなります。

micomiaでは、入退社時に確認する項目を整理し、確認できる運用を整備しています。

特に退職時には、アカウント停止だけではなく、会社支給端末の回収やローカルに保存された情報についても確認するなど運用を徹底しています。

9. 情報セキュリティ規程の整備

技術的な対策だけでは、会社全体の情報管理を統一することはできません。

そのためmicomiaでは、情報セキュリティに関する社内ルールについても整備を進めています。

例えば、アカウント管理や端末利用、入退社時のアクセス管理などです。

規程については、文書を作成すること自体を目的とせず、実際の業務で運用できる内容にすることを重視しています。会社としての方針は情報セキュリティ基本方針として公開しています。

10. インシデント発生時の対応

どれだけ対策を行っても、セキュリティインシデントの発生可能性を完全になくすことはできません。

重要なのは、問題が発生した場合にどのように対応するかを事前に決めておくことです。

例えば、端末の紛失、顧客情報の誤送信などが発生した場合、それぞれ初動対応が異なります。

micomiaでは、インシデント発生時の連絡・調査・対応・再発防止までを含めた運用についても整理しています。

11.ISO/IEC 27001取得を目的にしない

今回の情報セキュリティ体制整備では、ISO/IEC 27001の取得も一つの目標としています。

一方で、認証そのものを最終目的とはしていません。

重要なのは、お客様から預かった情報を適切に管理し、安心してシステム開発を任せていただける体制を継続的に維持することです。

セキュリティ対策は、一度ルールやシステムを導入すれば完了するものではありません。

利用するサービスや開発環境、組織体制が変化すれば、必要な対策も変わります。

そのためmicomiaでは、現在の環境に合わせて定期的に運用を見直し、必要に応じて改善していきます。

12.micomiaの情報セキュリティに関する取り組み

本記事では、micomiaで進めている情報セキュリティ対策の全体像を紹介しました。開発したシステムに対して実施している対策はセキュリティへの取り組みにまとめています。

システム開発を提供する企業として、開発するサービスだけでなく、開発を行う社内環境についても継続的にセキュリティの向上に取り組んでまいります。

セキュリティ体制についてのご質問や、開発のご相談はお問い合わせフォームからお気軽にどうぞ。