お知らせ

2016/08/27

• パソコン関連

Dropboxが2012年以前のパスワードをリセット

Dropboxが2012年以前のパスワードをリセット

Dropboxがメールでサービスの全ユーザーに対して、2012年以前に設定されたパスワードをそのまま利用しているユーザーのパスワードをリセットする旨の連絡を行いました。 これは文字どおり2012年以前からのユーザーにしか適合しないことで、それより後に利用を開始したユーザーには関係がありません。 Webサービスは常に攻撃者からの攻撃にさらされており、様々な防護策をとってはいますが、常に新しい脆弱性情報を隠し持つ攻撃者からの不正アクセスをストップすることは大変難しいことです。 今回Dropboxのセキュリティチームは自社の登録ユーザーの一部のメールアドレスと、ハッシュ化されたパスワードのデータがWeb上に存在することを発見したとのことです。 ハッシュ化されたパスワードというものは、パスワードそのものではなく、パスワードの文字列から一定の法則で導き出されるユニークな数値です。 ハッシュ化されたパスワードは加工はされていますが、一文字でも違えば全く違うユニークな数になるようになっており、またハッシュから元のパスワードへの再変換はほぼ不可能です。 これら情報が何らかの方法で外部に漏洩したことが発覚したため、2012年以前のパスワードの強制変更になったと発表されています。 その他、他のWebサービスからの漏洩のユーザー名とパスワードを利用して、他のWebサービスについて総当りでログインを試みるといった攻撃も絶え間なく続いています。 国際的なWebサービスはこのような事態から、ログインに用いられたIPアドレスなどから危険性を察知し、仮にログインに成功しても失敗したと応答する対策もあるようです。 IPアドレスは国別に割り振られており、ログイン試行された地域というものはおおよそわかるようになっています。かけ離れた地域からのログイン試行は遮断、あるいは本人であることを確認する仕組みが作られています。 ユーザーとしてできる最良の防護策はパスワードの使い回しを避けるということです。 たとえ複雑であったとしても、一度テキストのデータとして流出してしまえばパスワード攻撃の辞書に登録されて、他のサービスのログイン試行に用いられてしまいます。 定期的なパスワード変更というものは、ほとんどの場合においてオーバーで、またパスワード忘れを多発させることに伴う幾つかの潜在的なリスクもあります。 パスワードの使い回しを避け、またサービス運営企業からの告知についても注意を払うことがユーザーにとって今の所最善の対策と言えそうです。  

2016/08/20

• パソコン関連

プログラミング教育

プログラミング教育

このところ、プログラマやSEなどエンジニア職以外へのプログラミング教育がよく話題になっています。 義務教育内のプログラミング実習など国内でも多く取りざたされています。 プログラムを実際に作成する職種以外の方がプログラミングを学ぶことにどういった意味があるのでしょうか。 プログラミング、と言って最初に思い浮かべるのが、様々な言語の名前、JavaやC言語、Javascriptなどとっつきにくいという第一印象を持たれることが多いです。 ですがプログラミングで重要なことは、論理的なフローを考えて、それを構築するという考え方です。 演算と繰り返し処理と条件分岐の正しい設定がプログラミングの根本的な部分であり、それを覚えることはプログラムを作成する上での効率的な物事の進め方につながります。 条件分岐は例えばエクセルの関数の処理でも書くことができ、手作業でやっていた事柄も大幅に効率化が可能になることもあります。 これらを学ぶうちにわかることは、特に条件分岐においてプログラム作成時のエラーが発生することです。 パターンが多くなると例外が発生したり二重に計算を行ってしまったり、条件のとりにがしなどが発生しやすく、またそれら全パターンのテストを網羅しなければ顕在化しないということがわかります。 作成時は完璧に動作すると考えられたものでもきっちりとテストをしなければ、データが壊れてしまう、あるいは誤ったデータを信じて利用してしまうことも考えられます。 プログラムを学ぶうちにそのようなフロー作りの中で、人間の犯しやすいミスを学習することができます。 これらを学ぶことで実際にプログラム作成の業務に携わらなくとも、手近なツールを用いて業務などを効率化する考え方を手に入れることができます。

2016/08/19

• ブログ

古風なＳＥを目指して（第２回）

古風なＳＥを目指して（第２回）

暑さに負けているTKです。 古風なＳＥを目指している私が経験したことを書いていきます。 今回は「業務ＳＥへの道」ということで 私が経験した内容を書いていきます。 会社に入るまでは、システム開発の手順を知らなかったので プログラムを開発する＝システムエンジニアと思ってました。 実際、会社に入ってみてわかったのですが システムエンジニアはプログラムを作らないことが分かり驚いた記憶があります。 では何をするのかというと、機械のソフトメンテナンスや お客様との要件すり合わせ、プロジェクト管理等 私にはさっぱりわからないことだらけでした。 初めてシステム開発の要件すり合わせの打合せに連れて行ってもらったときは ちんぷんかんぷんでした。 話している先輩の姿を見て、なぜこんなにスラスラ話せるのだろうと思ってみていました。 それから数年が経ち、私にも要件定義から入るプロジェクトに出会いました。 サブ担当としてなので、主担当の方が概ね話してもらってました。 帰り際、次の打合せはメインで話すように言われ、心臓が飛び出そうになりました。 何も知らない会計のシステムで、経理担当の方やお偉い方の前で うまく話せるかがとても心配でした。 会社の帰りに会計の本を買って、少しでも知識を身につけようと思いましたが さっぱりわかりませんでした。 そんなこんなで、いざ打合せの日になり 作っていった資料で話を進めてましたが、 お客様からの質問に答えられず、主担当の方にほとんど答えて頂きました。 帰り際、業務ＳＥはお客様の信頼をいかに得るかが重要で、 信頼を得るためには、知識とお客様の業務内容をいかに早く把握するかを 努力しないといけないと言われました。 私が１人で要件定義を行うまで、それから４～５年かかりました。 確かに要件定義を行い、いろいろ質問されても答えられるようになると お客様からの信頼を得ることができるようになってきました。 今でも知識の習得とお客様の業務内容を早く把握することは心掛けています。 次回は、「大規模プロジェクト参画への心構え」でお会いしましょう。

2016/08/13

• パソコン関連

KintoneとSalesforceの違い

KintoneとSalesforceの違い

KintoneとSalesforceは国内のクラウドプラットフォームの導入でよく比較の対象になります。 筆者としては二つのプラットフォームは性格が違うものと考えていますが、比較対象になるだけに後発のKintoneもSalesforceの良い部分を取り込んでいっているようにも見えます。 システムとしては、Kintoneはカード型データベースに近いもので、Excelでデータベース的な管理を行っているもののクラウド化として特化しているようです。 Salesforceは本格的なリレーショナルデータベースとカスタマイズ用の詳細な言語設定があり、大掛かりなプラットフォームです。大規模な構築をすれば基幹業務にも利用出来る機能があります。 目的としてはKintoneは現場の業務効率化を最大の目的としているように感じます。 Excelによるデータ共有はごく簡易なことに向いているので、それをKintoneへの移行する場合は、形式とデータごと簡単に移してしまえます。 Excelでデータ共有している小さな現場のシステムをクラウド化することでより効率よくチーム作業を行うことができます。 Salesforceは非常に機能や拡張性が高い反面、業務の効率化に結びつくまでのカスタマイズには時間がかかります。 また現場レベルで新たなオブジェクトを起こすのでなく、ある程度要件やデータ型をきっちりと定義した上でないとマッチしにくいところはあると思います。 定着して業務に乗れば、現場レベルを超えて企業全体の効率化を図ることができるので、目標としては大きく設定されているように思います。 目標設定の大小の差があるので性格が違うものになると考えていますが、ニーズにマッチすればどちらもクラウドの良さを実感出来る良いサービスです。

2016/08/11

• パソコン関連

Dropboxの管理機能追加

Dropboxの管理機能追加

Dropboxが企業ユーザーに対して管理機能を追加するAdminXの先行公開をスタートしました。 今回のアップデートで大きく変わるのはチームフォルダの追加により、細くファイルの共有と共有範囲を設定できるようになりました。 チームフォルダで閲覧できるユーザーがサブフォルダについては書き込みも可能になるというような詳細なパーミッションの設定ができるようになりました。 Dropboxにはグループ機能というのがすでにあり、グループワーク向けに使えるのですが、パーミッションの細かさがそこまで細くならないというところに筆者としては不満はありました。 親のフォルダのパーミッションに子フォルダも合わせることになってしまうので、親フォルダ、子フォルダの設定はある程度計画的に行わなければいけません。 AdminXを利用すると個々のフォルダごとにユーザーの読み書きの権限を設定でき、Windows共有などと近い感覚で共有フォルダを作成することができます。 チームフォルダには外部と共有できるリンクを作成することが不可能ということで、その点の注意は必要そうです。 またPC同期クライアントでの同期の有無も管理者側で設定できるようになるということです。 今後の機能追加としてはモバイル機器の管理が管理者側からできるようになるようです。接続を許可したモバイルデバイスと、接続を許可しなモバイルデバイスを分けることができ、ファイルセキュリティの向上になりそうです。 Dropboxはオンラインストレージの先駆者でもあり、より使いやすさを追求して企業ユーザーの数を増やしていくきっかけとなるアップデートになるのではないかと感じます。

2016/07/28

• ブログ

Apple Musicでミュージックライフ

Apple Musicでミュージックライフ

こんばんは、いこまです。 Apple Musicの３か月お試しサービスになにげに登録してから、いろんな音楽を聴いて楽しんでます。 気になる曲があったら片っ端からライブラリやプレイリストに追加。 テーマを決めていろんなプレイリストを作るのも楽しいです。 最近のお気に入りのアーティストはアヴィーチーです。 「Wake Me Up」が有名。 無料期間の間に、お気に入りの曲、アーティストを探してみたいと思います。

2016/07/23

• パソコン関連

IPメッセンジャーとChatwork

IPメッセンジャーとChatwork

社内で使うインスタントメッセージアプリとして、システムキューブではChatworkを利用し始めるまではIPメッセンジャーを主に利用していました。 IPメッセンジャーは構内LAN環境のIPメッセンジャーをインストールしてある端末を自動で探索して表示してくれるので、個別のPCにインストールすればすぐメッセージやファイルのやり取りができるフリーソフトです。 IPメッセンジャーはIPメッセンジャーのためのサーバーが必要なく、PC同士がP2Pで通信をするので、管理というほどの管理を必要としないところが導入コストの少なさです。管理は必要ありませんが、管理ができないというところはあります。 メッセージは個別のPCにログファイルという形で残すことができます。これは単純なプレーンテキストで、複雑な検索などをする場合は別途テキストエディタなどがあると便利です。 IPメッセンジャー自体は非常にシンプルで、シンプルさ故に堅牢です。ネットワークが疎通していれば利用出来るという安定性があります。 社外へつなげるということには少し難度が高いです。特に拠点間の連絡であればVPNのような仕組みは必須です。 HamachiなどのソフトウェアVPNを利用すればWAN越しにIPメッセンジャーを利用することができますが、手順は増えます。 IPメッセンジャーに弱みがあるとすれば、スマートフォン対策です。スマートフォンアプリのIPメッセンジャーもあるのですが、同じLANに接続していることが条件になりますので、Wi-Fiの範囲を出ればメッセージの送信も受信もできなくなります。 スマートフォンでVPNは接続などにそれなりに手間が必要となりますので、常用を前提にするには結構な準備が必要となります。 スマートフォンとの統合されたインスタントメッセージという点で、Chatworkは非常に強いツールになっています。 機能としてはインスタントメッセージ、グループチャット、ファイル転送になりますが、ブラウザが動作するパソコン、スマートフォン、タブレットなど使える機種は幅広いです。 ログの検索についても、ユーザーごと、グループごとに分けて前文から検索をする機能もパワフルです。 スマートフォンを使うことで、スマートフォンの通知を使えることがインスタントメッセージの最高の強みになっています。 IPメッセンジャーに対する弱みといえば、インターネット接続がなければ構内LANだけの接続もできなくなってしまうところです。 ライセンスについてChatworkはクライアントごとに必要になります。フリーウェアであるIPメッセンジャーとは最も違うところです。 仕組み的に大きく違う二つのインスタントメッセンジャーですが、必要な時に素早くメッセージを送る手段として有益に活用するシーンを考えてみると良さそうです。

2016/07/18

• パソコン関連

Windowsとフリーソフトのセキュリティ

Windowsとフリーソフトのセキュリティ

Windowsを利用しているセキュリティ上のメリットは脆弱性への対処が定期的に比較的速やかに行われることです。 Linuxをはじめとしたオープンソースでも同様に脆弱性発見とその対処は行われていますが、IT系のニュースでとりあげられることはオープンソースの方が比率としては多いです。 多くのWebサービスがLinuxをベースとしたWebサーバーで成り立っているため、サーバー側の脆弱性がすぐにサービス運営者と利用者に影響が出ることがあるのもその一つの理由でしょう。 例としてOpenSSLというWebサイト暗号化に一般的に利用されるソフトウェアについては、この数年で何度か大きな脆弱性が報告されています。 Apacheを主としたWebサイトがOpenSSLを使っている割合が多いため、これらのニュースはサイト運営者にはとても重要なことになります。 マイクロソフトは自社開発のソフトウェアをWindowsの機能やアプリケーションとして提供しているので、これらオープンソースの脆弱性の影響をほとんど受けません。 あくまでWindowsはOSですので、Windows上で動作するアプリケーションやサーバーをマイクロソフト製品で揃える必要はなく、自由な組み合わせが可能です。 Windows上でオープンソースのソフトウェアを導入して利用する事例も多くあります。 WindowsとTomcatを利用したJavaのWebサービスや、GUIをApacheを利用して提供するソフトウェアも見られます。 どのような組み合わせも自由でその選択肢はとても多いのですが、様々なところに脆弱性の情報が分散してしまうということにもなります。 Windowsは大部分がプロプライエタリ(クローズドソース)でソース公開がされていないため、脆弱性の発見と修正のサイクルはオープンソースと大きく異なります。 漏れがないように情報を収集するのはもちろんですが、なるだけ情報を集約しやすいシステム設計について考慮すると運用コストが低減できます。 現在はクラウドを利用したサービスも増えてきていますが、クラウド基盤や、クラウド上のプラットフォームについても別途脆弱性が発生することもあります。 選択肢が広がることは良いことですが、同時に運用のための情報が拡散しやすい状態にもなっているように感じます。

2016/07/16

• パソコン関連

Windows 10月額制プラン

Windows 10月額制プラン

マイクロソフトはWindows10を月額制で提供するWindows10 Enterprise E3プランを発表しました。 この秋にも提供を開始し、月額費用は7ドルを予定しているようです。 日本での提供については現在のところ情報はありませんが、今後の発表が待たれます。 月額制でWindowsを購入するメリットとしては、初期費用がかからないということや、最新のWindowsをいつでもダウンロードして使い始めることができる、ライセンスキーの管理が不必要というところです。 他のマイクロソフトの月額制商品はライセンスキーではなく、紐付けされたメールアドレスによって認証し、有効期間が切れれば認証が通らなくなって利用できなくなるという形を取っています。 多くのPCはDSP版というパッケージで、パソコンメーカーに対してマイクロソフトが提供したライセンスをプリインストールした状態で購入することが多いです。 プリインストールされたものに対してWindowsの費用というものはあまり意識をしませんが、単体で購入すれば2万円以上するソフトウェアです。 ライセンスキーの形でライセンス管理は導入台数が増えれば増えるほど管理コストが高くなります。 このパソコンにインストールしているライセンスキーはどの番号か、などのコストを解決するためにボリュームライセンスもありますが、それでも新規購入したバージョン違いのWindowsなど、時間が経てば問題がどんどん複雑になります Windows10 Enterprise E3プランがOffice 365などと同じ形をとるのであれば、必要なアカウント情報の入力で既にインストールされているライセンス数と、使っていないPCの非アクティブ化、インストールなど管理コストがとても簡単になります。 マイクロソフトの主力開発商品であるVisual Sudioもクラウドサブスクリプションという月額制プランが提供されており、マイクロソフトの主力商品の管理が今後もよりユーザーによって使い易いものになっていきそうです。

2016/07/14

• ブログ

古風なＳＥを目指して（第１回）

古風なＳＥを目指して（第１回）

雨にも負けて、風邪にも負けているTKです。 古風なＳＥを目指している私が経験したことを書いていきます。 そもそもＳＥとして動けていたかどうかはわかりませんが、 コンピュータ会社に入り、お客様と話をする。 私のＳＥの原点がそこにありました。 学生時代はコンピュータを触っていれば、 仕事をこなせると思っていたので、 会社に入ってからは、コンピュータに触る機会が少なく、 お客様との打合せや机上プログラミングが主だったので 結構ギャップが大きかったです。 そのそもＳＥとは何かをわかっていませんでした。 特に新人時代のお客様打合せでは、先輩についていき 眠くなりながら話しを聞いていました。 打合せ後に議事録を作成するよう言われ、 １週間ぐらい掛けて作成し、 内容も作成の遅さにも怒られた記憶があります。 私は人前でのおしゃべりがうまくなく、また打ち合わせ内容が わからなかったのでなかなか発言できませんでした。 そうこうしているうちに、入社から半年ぐらいが経ち 私も１人で打合せに出かけることがありました。 分かる範囲で準備をし訪問しました。 ただ、わからないことが多かったので 打合せがすぐに終わってしまいました。 ある意味先輩に試されたと思います。 ただ、１人で打合せを行うと 自分がしゃべらなければ、話が進まないので 準備とそれなりの知識が必要だということを実感でき 貴重な体験となりました。 今でも準備不足の場合、話が詰まることがあるので 原点に戻らなければと思うことがあります。 次回は、「業務ＳＥへの道」でお会いしましょう。