SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

EnterpriseZine(エンタープライズジン)編集部では、情報システム担当、セキュリティ担当の方々向けに、EnterpriseZine Day、Security Online Day、DataTechという、3つのイベントを開催しております。それぞれ編集部独自の切り口で、業界トレンドや最新事例を網羅。最新の動向を知ることができる場として、好評を得ています。

最新イベントはこちら!

EnterpriseZine Day Special

2024年10月16日(火)オンライン開催

EnterpriseZine(エンタープライズジン)編集部では、情報システム担当、セキュリティ担当の方々向けの講座「EnterpriseZine Academy」や、すべてのITパーソンに向けた「新エバンジェリスト養成講座」などの講座を企画しています。EnterpriseZine編集部ならではの切り口・企画・講師セレクトで、明日を担うIT人材の育成をミッションに展開しております。

お申し込み受付中!

間違いだらけのクライアント・セキュリティ対策

「セキュリティファースト」を現実的にどう実現すべきか?


 「モバイルファースト」や「クラウドファースト」は筆者の勤務するマイクロソフトのビジネスの目標にもなっています。サーバーはオンプレミス、端末はPCのみ、社内事務所だけでそれらを利用する……という制約のある従来の環境から変わっていく姿を示していると言えます。また、在宅勤務を代表する働き方の変化や、多様な人材が活躍する社会を支えていくための基盤という意味合いもあるでしょう。同様に、システムの実装・運用の設計においてはセキュリティを最初に考えておくべき、つまり「セキュリティファースト」が重要です。ここでいうセキュリティファーストとは、何よりも優先すべきはセキュリティということではなく、“設計時にセキュリティを考慮しておくことの重要性”を意図しています。あとからセキュリティを見直す必要が生じても、実際にはその対応が困難なケースがあります。今回は具体例を交えながら、セキュリティファーストの重要性を解説していきます。

あとからセキュリティ強化策を実装するのは困難

 「モバイルファースト」「クラウドファースト」という目標は、なかなか企業で実現できないからこそ “スローガン”となっている側面があるように、「セキュリティファースト」も十分に実現できておらず、設計時点でセキュリティの考慮がなされていない傾向があります。

 そこでまず、具体例を紹介しましょう。本連載では繰り返し、セキュリティの特性(機密性、完全性、可用性)を維持するためには認証が重要であることを解説しています。その重要性があまり考慮されていない例として、ローカル認証において、すべてのPCのローカル管理者のIDとパスワードが同一になっていることを悪用されていることを取り上げています。

 この改善策としてAdministratorというOSのデフォルト値の管理者用のアカウント名を変更することや、パスワードをPCごとに個別にユニークにすることが挙げられます。また、これを機に従来パスワードの長さが6文字だったものを8文字にして、少しでも推測されにくいものにしようと改善が試みられるケースもあります。

 技術的には大して難しい問題ではなく、過去の連載でも紹介したグループポリシーやLAPSというツールの適用で、比較的簡単にこうした目標は達成できるはずです。ところが、現実にはそうは簡単にはいかない場合があるのです。

  • 独自開発したシステムでパスワード6文字固定の入力フィールドにしているシステムがあるので、そのシステムを改修するまではパスワードを8文字以上にすることなどできない。また、こうしたパスワード文字数に制限のあるシステムが他にもあるか分からないので、調査しないとパスワードの強化策に着手できない。
  • スクリプトやバッチで Administrator というアカウントとパスワードを埋め込んでいるので、どんなシステムにどんな影響があるのか分からない。

 といった場合です。こうした事情から、大規模な環境ではそう簡単にセキュリティ強化策は実装できないことがお分かりいただけると思います。しかし、まさにこれはセキュリティファーストを目標としてこなかった実装が招いた結果と言えます。 

  • アプリケーションの開発時点で、パスワードの長さを固定ではなく可変に対応しておく 
  • そもそもスクリプトやバッチに本当に管理者権限が必要かを検討する 
  • やむを得ず管理者権限が必要だとして、OSのデフォルト値をそのまま使わずAdministrator以外の名前になっても対応できるようにしておく 
  • スクリプトやバッチの中に認証処理を必要としない方式を検討する 
  • それでも事情によりこうした運用が避けられないときは、それを監視したり、定期的に監査し、何かあったときにはすぐに現在の運用が提示できたり、説明できるようにする

 結果論と思われるかもしれませんが、どれも実装前に検討可能なことばかりではないでしょうか。

次のページ
セキュリティファーストをどう実現していくべきか?

この記事は参考になりましたか?

  • Facebook
  • X
  • Pocket
  • note
間違いだらけのクライアント・セキュリティ対策連載記事一覧

もっと読む

この記事の著者

香山 哲司(カヤマ サトシ)

ジーブレイン株式会社 コンサルティング事業部 シニアコンサルタント 2001年、マイクロソフト株式会社(現、日本マイクロソフト株式会社)に入社、エンタープライズサービス部門に所属。主にインフラ領域のITコンサルティングに従事。電力・ガス会社、また政令指定都市向けの大規模環境における認証基盤やス...

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

この記事は参考になりましたか?

この記事をシェア

EnterpriseZine(エンタープライズジン)
https://enterprisezine.jp/article/detail/8151 2016/06/20 17:55

Job Board

AD

おすすめ

アクセスランキング

アクセスランキング

イベント

EnterpriseZine(エンタープライズジン)編集部では、情報システム担当、セキュリティ担当の方々向けに、EnterpriseZine Day、Security Online Day、DataTechという、3つのイベントを開催しております。それぞれ編集部独自の切り口で、業界トレンドや最新事例を網羅。最新の動向を知ることができる場として、好評を得ています。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー

アクセスランキング

アクセスランキング