ライタス株式会社公式ブログ

7-Zip（せぶんじっぷ）というフリーの圧縮解凍ソフトをご存知でしょうか。 https://sevenzip.osdn.jp/ オープンソースで開発されており、Windows用の圧縮解凍ソフトとして愛用しています。歴史は長く、2000年から開発されているようです。（ Wikipedia より） コマンドラインでも使えることから、バッチで使用したり、7-zip形式の高圧縮を実現してみたりと、素晴らしい活躍を見せてくれています。 インストールが英語なので、ちょっと取っつきにくいかも知れませんが、日本語プロジェクトもあり、こちらも最新版が提供されていました。騙されたと思って是非試してみてください。 https://osdn.jp/projects/sevenzip/ 今回は、5年ぶりの正式版リリースということで、ニュースを見るまでアップデートを忘れておりましたので、この機会にアップデートしました。 使用感は変わらないのですが、いろいろなバグが修正され、新機能も追加されたようです。 特にコマンドラインのオプションが増えたようなので、取り上げてみます。 コマンドラインで見ると、以下のようになりました。 7-Zip [64] 15.12 : Copyright (c) 1999-2015 Igor Pavlov : 2015-11-19 Usage: 7z <command> [<switches>...] <archive_name> [<file_names>...] [<@listfiles...>] <Commands> a : Add files to archive b : Benchmark d : Delete files from archive e : Extract files from archive (without using directory names) h : Calculate hash values for files i : Show information about supported formats l : List contents of archive rn : Ren...

CSIRT (シーサート: Computer Security Incident Response Team) は、IT分野の消防団的な立ち位置のチームで、主に火消し・・・といっても火が出ているわけではありませんが、セキュリティインシデントが発生した時に、その状況を収め、一次対応を行います。 CSIRTの普段の活動としては、情報収集や情報共有、組織内向けのセキュリティセミナー、他のCSIRT同士の情報交換などを行います。また、いざというときは、ナレッジを元に対応したり、外部の技術者を必要に応じて召喚して、収集にあたったりといったことを行います。組織内に作られることが多いですが、そうでないJPCERT/CCのような組織に属さない組織もあります。 今回改定されたのは、CSIRTの作り方とも言えるマニュアルというかガイドラインのようなものです。 http://www.jpcert.or.jp/csirt_material/index.html よくまとまっていると思うので、社内のセキュリティが甘いと考えている方は、是非このCSIRTマテリアルを一度通読されることをおすすめします。 弊社では、CSIRTの導入によって、組織内で発生したセキュリティインシデントに対する意識が変わるというのが、一番の効果だと思っています。 この部分をうまくお伝えすることができないのは、問題だと自覚していますが、セキュリティの最後の砦は、人間の意識だと考えており、これを強化するのは、どのような組織であっても効果的であると考えています。 インターネットを利用した業務を遂行する上では、リスクが存在します。しかし、リスクを減らす取り組みを継続的に行うことで、リスクを低減させることが可能です。CSIRTを編成したからといって、すべてがうまくいくわけではありませんが、検討するに値する内容だと思います。

昨日ポストした 投稿 を意図したわけではないのですが、総務省から「電気通信事業法等の一部を改正する法律の施行等に伴う電気通信事業の利用者保護に関する省令等の整備案についての意見募集」という発表が行われました。 http://www.soumu.go.jp/menu_news/s-news/01kiban08_02000194.html 動向は把握しておりましたが、パブリックコメントとなると、いよいよ改正に向けての最終段階に入ってきたと思われます。 主な改正ポイントは、電気通信事業者及び媒介等業務受託者（代理店）に対して １．説明義務の充実 ２．書面の交付義務の導入 ３．初期契約解除制度の導入 ４．勧誘継続行為の禁止 ５．代理店（媒介等業務受託者）に対する指導等の措置 を追加する内容となるそうです。 読んでみていただければわかると思いますが、電話網・インターネット網を主体的に運営・販売している会社に対しての内容であったので、クラウド事業者が気にしなくても良いかもしれません。 しかしながら、クラウド環境を代理店販売をしている事業者の場合、仕入元から監督される立場になりますので、該当する場合は注意が必要です。 パブリックコメント中なので、この内容がそのまま法規に採用されるとも決まっているわけではありませんが、該当する方はご注意ください。

システムのコンサルティングをさせていただくときに、電気通信事業法の話を時々させていただきます。 ほとんどが、電話屋さんの規制と捉えられ、意外と知られていないようなので、弊社としての認識を明らかにしつつ、クラウドでシステムを開発するときに注意すべきポイントについて概説します。（本投稿では第1種、第2種通信事業者は除いています） ※注意：弊社の見解です。法律面につきましては、弁護士や司法書士などの専門家にご相談ください。 電気通信事業法とは、総務省所管の法律で、昭和60年4月に施行されました。 法律の文面はこちらからご覧いただけます。 http://law.e-gov.go.jp/htmldata/S59/S59HO086.html これまでの改正の経緯も調べれば出てくるのですが、それは別の機会にしたいと思います。 本法律の要旨は以下のとおりと認識しています。 ・電気通信とは 電気を使った通信のことです。 法律では、「有線、無線その他の電磁的方式により、符号、音響又は影像を送り、伝え又は受けること」と定義しています。 ・電気通信事業とは 電気通信で商売することですが、法律では「電気通信事業法第2条に規定する電気通信役務を行う事業」と定義しています。 第2条については、法律のリンクを参照ください。 ・電気通信事業者とは 電気通信事業を行う事業者のことです。 ・検閲の禁止 通信を見て検閲してはいけないことになっています。 いわゆる通信の秘密と言われるものは、ここで定義されています。 検閲の禁止は、電気通信事業者だけではなく、すべての人に適用されるものです。 これは、国家に対しても同様であり、表現の自由を守るための条文として理解されています。 ・秘密の保護 電気通信事業者は、その役務の都合で通信の内容が見える立場にいます。 見えるのはしょうがないとしても、必ず通信の内容を守ることが規定されています。 ・電気通信事業の登録 ここが重要ポイントですが、電気通信事業を営む者は、総務大臣に届け出をしなければならないことになっています。 大規模設備を持つ事業であれば、電気通信事業者の登録を、小規模であれば届け出をする必要があります。 届出のフォームは総務省からダウンロードできます。 ...

昔から、チラチラ見るエラーで、サーバーとしては対策の必要もないだろうと思って放置していたのですが、 問い合わせがあったのでメモ。 Source: crypt32   Message: < http://www.download.windowsupdate.com/msdownload/update/v3/static/trustedr/en/authrootstl.cab > にある自動更新 cab ファイルからサードパーティのルート一覧を抽出できませんでした。エラー: 現在のシステム時計または署名ファイルのタイムスタンプで確認すると、必要な証明書の有効期間が過ぎています。 内容としては、プリインストールされているサーバー証明書の更新に失敗すると出るエラーのようです。 証明書は、基本的にはWindows Updateにて配布されるのですが、これの更新に失敗する事例があるそうです。 詳しい話と、その対策は、以下のサイトに記載があります。 http://blogs.technet.com/b/jpntsblog/archive/2010/07/22/crypt32-windows-xp-windows-server-2003-microsoft-windows-capi2-windows-vista.aspx 放置していたサーバーで、対策してみたので、効果を期待してます。 本記事は、弊社代表のブログ記事 なんでもIT屋の宿命 からの転載です。

前回の記事 に続き、技術面からSSLサーバー証明書の導入に関して、気をつけなければならないポイントを概説したいと思います。 注意ポイント１：暗号の強度 暗号の強度と言われても難しいと思いますが、重要なポイントです。 現在、だいたいの証明書ベンダーは2048bit以上の鍵を使った証明書でないと発行してくれない状態になっていますが、たまに1024bit長の鍵を受容するベンダーがあるようなので、秘密鍵の作成のときには、注意が必要です。 また、SHA-2での申請を要するようになってきましたので、そちらも証明書ベンダーの手順書などでご確認ください。 Symantec(元Verisign）は、楕円暗号方式をサポートしている証明書ベンダーなのでより強固な暗号化を実施したい場合はこちらも選択肢に入るかと思います。 注意ポイント２：記載内容 CSRを作成するときに、フレンドリ名や組織の内容を記載しますが、記載を極力正確に記載します。特にドメイン名（FQDN）を間違えると、せっかく購入した証明書が無駄になってしまうことがあります。 注意ポイント３：中間証明書 中間証明書とは、ルート証明書とサーバー証明書をつなぐ役割を果たす証明書です。文字で書いてもよくわからないので、絵を用意しました。 中間証明書をインストールするのはサーバー側なので、ここをミスするとサーバー証明書を入れた意味がありません。 中間証明書をチェックするサイトもありますので、インストール後にそちらでチェックすることをおすすめします。 また、クロスルート証明書が必要なケースもありますので、必ずインストールする際には、ベンダーが公開しているインストール手順にしたがって行う必要があります。 注意ポイント４：証明書のバックアップ 証明書のインストールが終わったら、証明書のバックアップを取得することをおすすめしています。 これは、サーバー証明書を再発行するときは有料になってしまうことや、ハードウェアに障害が発生したなどの場合に素早く復旧するときに使うことを想定してのことです。 バックアップした証明書の保管は、頭を悩ませるポイントですが、可能な限りネットワークに置かず、暗号化を施した後、CD-RやUSBメモリに保管し、金庫などで保管というのが、良さそうなシナリオです。他にもセ...

2015年11月11日に、マイクロソフトよりHyper-Vの脆弱性についての報告がありました。 本脆弱性は、KB3108604として修正されています。 詳しい内容は以下をご参照ください。 https://technet.microsoft.com/ja-jp/library/security/3108638 驚くべきところは、ゲストOSの特権を使えば、ホストOSをサービス停止させることができるという点ですね。 CPUの弱点を突く攻撃がゲストOSから可能であるということなので、修正されることをおすすめします。 また、Hyper-Vだけかと思ったら、XenやKVMにも同様の脆弱性を持っているようで、こちらも修正パッチがリリースされているようです。 http://jvndb.jvn.jp/ja/contents/2015/JVNDB-2015-005933.html http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-8104 http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-5307 メカニズムについては、分かる範囲で調べてみました。 ポイントは、CPU命令に搭載されているアライメントチェック（Alignment Check）の例外処理が誘発されることに起因します。アライメントチェックとは、メモリからCPUの命令を電送するときに、ちゃんとデータを送り届けるために整列（アライン）させます。これが正しく整列されているかをチェックする仕掛けが、アライメントチェックと言います。 詳しい解説は以下をご覧ください。非常に丁寧に解説されています。 http://www5d.biglobe.ne.jp/~noocyte/Programming/Alignment.html 今回の脆弱性は、アライメントチェックを利用して、CPUにアライメントチェック例外を引き起こす事ができるというもので、これが引き起こされた場合、Windowsであれば、ブルーバックになるものと思われます。 最近のWindowsはブルーバックになると、自動的に再起動されるので、原因が掴みかねる場合もありそうです。 Linuxではカーネル...